Flussdiagramm User Provisioning (Eintritt, Wechsel, Austritt)
Flussdiagramm für das User Provisioning: HR-Ereignis, Identität im Verzeichnis, Zugangsdaten und MFA, Berechtigungspaket der Rolle, Freigabe für privilegierte Rechte, nachgelagerte Konten, Verifizierung und Rezertifizierung.
Was ist flussdiagramm user provisioning (eintritt, wechsel, austritt)?
User Provisioning scheitert leise, und genau deshalb wird es meist nach einem Audit in Ordnung gebracht statt davor. Die Eintrittshälfte ist sichtbar: Wer am ersten Tag ohne Postfach dasteht, beschwert sich, und jemand kümmert sich darum. Alles andere ist unsichtbar. Zugriffe werden von der Person kopiert, die zuletzt auf dem Stuhl saß, und so wird ein überversorgtes Konto zum Maßstab der ganzen Abteilung. Externe kommen ohne HR-Datensatz, ohne Ablaufdatum und mit einem Sponsor, der das Haus längst verlassen hat. Die eine Hälfte der Systemlandschaft liegt hinter Single Sign-on und wird automatisch bereitgestellt, die andere (das Finanzpaket, das per Kreditkarte beschaffte Werkzeug eines Teams, das Lieferantenportal) ist eine manuelle Warteschlange, die niemand misst. Und ein interner Wechsel ergänzt, ohne je zu entziehen, weil nirgends etwas meldet, dass ein Zugriff bloß überflüssig geworden ist. Nichts davon erzeugt einen Vorfall. Es erzeugt eine langsame Anhäufung, die Jahre später als Prüfbefund einer Zugriffsüberprüfung auftaucht, als nicht bestandener Kontrolltest oder als Konto einer längst ausgeschiedenen Person, das sich immer noch anmeldet.
Dieses Diagramm zeigt die Identitäts- und Kontenmaschinerie, nicht das Antragsformular und nicht die Freigabekette. Eine Person, die bereits auf ihrer Stelle sitzt und eine weitere Berechtigung braucht, mitsamt Freigaben und Rezertifizierungszyklus, gehört in den Berechtigungsantrag unter /de/templates/berechtigungsantrag-prozess; derselbe Antrag, ausgelöst durch einen Eintritt oder Rollenwechsel in HR und über ein Rollenprofil zugeschnitten, steht unter /de/templates/berechtigungsvergabe-mitarbeiter-prozess. Der Zugriff auf einen Datenbestand, über den ein Dateneigentümer nach Schutzbedarf und Zweck statt nach Stellenrolle entscheidet, steht unter /de/templates/datenzugriffsantrag-prozess. Der Austrittspfad ist hier bewusst kurz und übergibt dann: Der vollständige Ablauf der Deprovisionierung (mit Sammel- und Dienstkonten, deaktivieren gegen löschen und Nachweisführung) steht unter /de/templates/berechtigungsentzug-prozess. Verträge, Vorprüfungen, Arbeitsmittel und der erste Tag gehören zu /de/templates/mitarbeiter-onboarding-prozess. Übrig bleibt alles zwischen dem Ereignis und einem funktionierenden, verifizierten, dokumentierten Satz von Konten (die Identität, das Zugangsmittel, das Berechtigungspaket, die nachgelagerte Systemlandschaft) und dazu die eine Gruppe, die keine dieser Seiten trägt: die externe Person, die überhaupt keinen HR-Datensatz hat. In der Sprache der Maßnahmen ist das die Identitätshälfte von Anhang A der ISO/IEC 27001:2022: A.5.16 Identitätsmanagement, das den gesamten Lebenszyklus einer Identität regelt, und A.5.17 Authentifizierungsinformationen, das das dagegen ausgegebene Zugangsmittel regelt, und nicht A.5.15 und A.5.18, die regeln, worauf diese Identität dann zugreifen darf.
Drei Entscheidungen sind hier gezeichnet, die die meisten Provisionierungsverfahren stillschweigend voraussetzen. „Mitarbeitende oder Externe?“ steht vor der Existenz der Identität, denn eine externe Person braucht einen benannten Sponsor und ein Ablaufdatum, die ein HR-Zulauf nie liefern wird, und eine ohne beides angelegte Identität ist genau die verwaiste Identität, die eine Zugriffsüberprüfung zwei Jahre später findet. „Im Standardpaket enthalten?“ teilt den Ablauf in zwei Hälften: Alles im Paket der Rolle wird automatisch bereitgestellt, ohne dass jemand im Weg steht, und nur privilegierte oder zusätzliche Berechtigungen gehen an einen Verantwortlichen: das ist es, was die Freigabe davor bewahrt, zum Stempel auf Postfächern zu verkommen. Und „Bereitgestellte Zugriffe wie beantragt?“ ist eine echte Schranke und keine Schlussformalie, denn sie liest zurück, was die Zielsysteme wirklich gewähren, und hält es gegen das Beantragte; Berechtigungen, die ohne Freigabe angekommen sind, meldet die Person, die sie erhalten hat, niemals. Der Zweig für den Rollenwechsel ergänzt eine vierte, „Alte Rechte außerhalb des neuen Pakets?“, und die Rezertifizierung eine fünfte, „Berechtigungen passen noch zur Rolle?“, und beide münden in denselben Entzugsschritt, sodass es einen einzigen Weg aus einer Berechtigung heraus gibt, gleich wie der Bedarf an ihrem Entzug aufgefallen ist.
Was dieses Flussdiagramm abdeckt
In dieser Vorlage
- Sechs Phasen (Auslöser, Identität, Berechtigungen, Bereitstellung, Verifizierung sowie Änderung und Überprüfung) über fünf Swimlanes: HR oder Sponsor, IAM-Team (Identity and Access Management), Führungskraft, Berechtigungsverantwortlicher und Informationssicherheit.
- Ein Einstiegspunkt für fünf Ereignisse. „Welches Identitätsereignis?“ führt Eintritt, Rollenwechsel, Austritt, eine Break-Glass-Anforderung und eine geplante Rezertifizierung durch dasselbe Diagramm, sodass die Maschinerie geteilt und nicht für jeden Fall neu erfunden wird.
- Die Identitätsphase vollständig: „Mitarbeitende oder Externe?“ schickt Auftragnehmer, Zeitarbeitskräfte und Servicepartner über „Sponsor und Ablaufdatum erfassen“ (den einzigen Schritt, der ihnen einen verantwortlichen Eigner und ein Enddatum gibt), bevor beide Wege bei „Identität im Verzeichnis anlegen“ und „Zugangsdaten ausgeben und MFA einrichten“ zusammenlaufen.
- „Im Standardpaket enthalten?“: der Zweig Standard führt direkt zu „Standardpaket automatisch bereitstellen“, ohne Freigebenden im Weg, während privilegierte und zusätzliche Berechtigungen zu „Berechtigungsverantwortlicher gibt frei?“ gehen, dessen Zweig Abgelehnt bei „Berechtigung abgelehnt und geschlossen“ endet.
- Die Bereitstellung in der Reihenfolge, in der das Diagramm sie durchläuft: „Standardpaket automatisch bereitstellen“, dann „Konten in nachgelagerten Systemen anlegen“ für die automatisierte wie für die manuelle Systemlandschaft, dann „Bereitgestellte Zugriffe wie beantragt?“, dessen Zweig Abweichung über „Über- oder Untervergabe korrigieren“ läuft und erneut prüft, statt das Ticket zu schließen.
- Die Änderungshälfte: Beim Rollenwechsel wird „Alte Rechte außerhalb des neuen Pakets?“ gefragt, und alles Gefundene geht an „Überholte Berechtigungen entziehen“, bevor es zurück zu „Im Standardpaket enthalten?“ läuft; ein Austritt erreicht „Übergabe an den Berechtigungsentzug“; und „Berechtigungen passen noch zur Rolle?“ schickt eine abgewichene Antwort an denselben Entzugsschritt.
Wann Sie diese Vorlage verwenden sollten
- Sie schreiben das Kapitel zu Identitäten und Zugriffen in einem IT-Betriebshandbuch und brauchen ein einziges Bild dessen, was zwischen einem HR-Ereignis und einem Satz funktionierender Konten geschieht.
- Sie stehen vor der Beschaffung oder Einrichtung eines Werkzeugs für Identity Governance und wollen die Verzweigungen geklärt haben (was automatisch bereitgestellt wird, was einen Verantwortlichen braucht, was manuelle Warteschlange bleibt), bevor der Standard-Workflow eines Anbieters das für Sie klärt.
- Zugriffsüberprüfungen fördern immer wieder Berechtigungen aus Stellen zutage, die die Betroffenen vor Jahren verlassen haben, und Sie brauchen den Entzugsschritt beim Rollenwechsel mit Verantwortlichem und Termin gezeichnet.
- Ihre Systemlandschaft ist voller Externer (Auftragnehmer, Zeitarbeitskräfte, Prüfer, Partner, technische Konten), und keiner von ihnen kommt aus dem HR-Zulauf, auf dem der Rest des Ablaufs beruht.
- Eine Prüfung, ein Sicherheitsfragebogen eines Kunden oder ein ISO-27001-Audit hat gefragt, wie Identitäten entstehen, wie Berechtigungen vergeben werden und woher Sie wissen, dass die vorhandenen Zugriffe die freigegebenen sind.
So funktioniert es
Benennen Sie die Bahnen nach Ihren eigenen Rollen
Ersetzen Sie HR oder Sponsor, IAM-Team, Führungskraft, Berechtigungsverantwortlicher und Informationssicherheit durch die Rollen, die es bei Ihnen wirklich gibt. Halten Sie HR und Sponsor bewusst in einer Bahn: Es ist dieselbe Aufgabe für unterschiedliche Personengruppen, und sie zu trennen ist der Weg, auf dem für Externe am Ende niemand zuständig ist. Die Bahn des Berechtigungsverantwortlichen ist die, von der die meisten Häuser feststellen, dass sie unbesetzt ist. Können Sie heute für Ihre privilegierten Berechtigungen keinen Verantwortlichen benennen, ist diese Lücke ein Befund und kein Formulierungsproblem. Die Bahn sollte sichtbar leer im Diagramm stehen bleiben, bis sie geschlossen ist.
Erklären Sie Ihre führende Quelle, und wen sie nicht enthält
Das Diagramm setzt einen verbindlichen Zulauf für Eintritte, Rollenwechsel und Austritte voraus. Schreiben Sie auf, welches System das ist, welche Felder es führt (Stellenrolle, Führungskraft, Eintrittsdatum, Wirksamkeitsdatum einer Änderung, letzter Arbeitstag) und wie schnell eine Änderung dort erscheint. Schreiben Sie danach auf, wer nicht darin steht. Auftragnehmer, Aufsichts- und Beiratsmitglieder, Zeitarbeitskräfte, Praktikanten und technische Identitäten stehen meist nicht darin, und jede dieser Gruppen braucht ein eigenes Register und einen eigenen Sponsor, bevor der Rest des Ablaufs überhaupt laufen kann.
Schreiben Sie die Berechtigungspakete, bevor Sie veröffentlichen
„Berechtigungspaket der Rolle ableiten“ bleibt wirkungslos, solange die Pakete nicht existieren. Beginnen Sie mit den zehn Rollen, die Sie am häufigsten besetzen, und schreiben Sie auf, was jede davon am ersten Tag wirklich braucht. Wo Sie Anmelde- oder Nutzungsdaten haben, bauen Sie das Paket aus dem, was die heutigen Stelleninhaber tatsächlich nutzen, und nicht aus dem, was sie halten; der Abstand zwischen beidem ist in der Regel groß, und er ist der ganze Grund, warum sich das Schreiben lohnt. Halten Sie jedes Paket als Untergrenze und nicht als Obergrenze, damit alles darüber hinaus sichtbar genug bleibt, um beantragt zu werden.
Legen Sie die Schwelle für die Freigabe fest
„Im Standardpaket enthalten?“ funktioniert nur, wenn die Kriterien danebenstehen. Übliche Auslöser für den Freigabezweig sind Administrator- und Root-Rechte, Zugriff auf Produktivsysteme, Zahlungs- und Entgeltsysteme, personenbezogene und Gesundheitsdaten sowie alles, was die Zugriffe anderer Personen verändern kann. Prüfen Sie diese Liste gegen die Vergaben des letzten Quartals, bevor Sie sie veröffentlichen: Ein Kriterium, das die meisten davon einfängt, ist kein Kriterium. Läuft alles über einen Berechtigungsverantwortlichen, treffen Freigaben schneller ein, als sie jemand lesen kann, und die Kontrolle wird zur Warteschlange, durch die man sich zu klicken lernt.
Machen Sie den Entzug beim Rollenwechsel zur nachverfolgten Pflicht
„Überholte Berechtigungen entziehen“ ist der Schritt, der darüber entscheidet, ob Zugriffe in Ihrem Haus anwachsen. Geben Sie ihm dasselbe Ticket, denselben Verantwortlichen und denselben Termin wie der Vergabe, und schließen Sie den Rollenwechsel erst, wenn beide Hälften erledigt sind: ein Ticket, das mit der Eintrittshälfte schließt, ist der Mechanismus, durch den der Entzug nie stattfindet. Das Diagramm legt den Abgleich bewusst zur Führungskraft und nicht zum IAM-Team: Das Team kann die Liste der Unterschiede erzeugen, aber nur die Führungskraft weiß, ob eine Berechtigung wirklich überholt ist oder noch für eine Übergabe gebraucht wird.
Gehen Sie es mit den Beteiligten durch und veröffentlichen Sie eine Fassung
Klären Sie vor der Veröffentlichung die beiden Zweige, für die von Haus aus niemand zuständig ist. Entscheiden Sie, wer außerhalb der Geschäftszeiten Break-Glass auslösen darf und wer das Sitzungsprotokoll danach liest, und entscheiden Sie, wer bei der Rezertifizierung auf eine Antwort „Abgewichen“ hin handelt und bis wann, denn eine Überprüfung, die eine Liste erzeugt, aus der niemand entzieht, ist schlechter als gar keine. Gehen Sie das Diagramm danach mit einem Service-Desk-Mitarbeitenden durch, mit einer Führungskraft, die kürzlich eingestellt hat, und mit der Person, die zuletzt eine Zugriffsüberprüfung durchgeführt hat, und korrigieren Sie es auf das, was wirklich geschieht. Veröffentlichen Sie die korrigierte Fassung, halten Sie die Vorgänger lesbar, und verweisen Sie aus Ihrer Zugriffsrichtlinie darauf.
Häufig gestellte Fragen
Welche Schritte umfasst ein User-Provisioning-Prozess?
Ein Ereignis für Eintritt, Rollenwechsel oder Austritt aus dem führenden System übernehmen; entscheiden, ob es sich um Mitarbeitende oder Externe handelt, und Externen einen Sponsor und ein Ablaufdatum geben; eine Identität im Verzeichnis anlegen oder zuordnen, mit einem Bezeichner, der nie wiederverwendet wird; Zugangsdaten ausgeben und die Mehr-Faktor-Authentifizierung gegen diese Identität einrichten; das Berechtigungspaket der Stellenrolle ableiten; alles innerhalb dieses Pakets automatisch bereitstellen und privilegierte oder zusätzliche Berechtigungen zur Freigabe an den Berechtigungsverantwortlichen leiten; Konten in den nachgelagerten Systemen anlegen, in den automatisierten wie in der manuellen Warteschlange; prüfen, ob das, was die Systeme tatsächlich gewähren, dem Beantragten entspricht; die Führungskraft bestätigen lassen; und die Berechtigungen zur Identität dokumentieren. Danach läuft der Prozess weiter: Ein Rollenwechsel leitet das Paket neu ab und entzieht, was die alte Rolle nicht mehr rechtfertigt, ein Austritt führt zur Deaktivierung und zur Übergabe an den Entzug, und die Rezertifizierung prüft in festem Takt, ob Berechtigungen und Rolle noch zusammenpassen.
Was ist ein Berechtigungspaket für eine Rolle (Birthright Access)?
Es ist der Satz an Zugriffen, den eine Stelle an ihrem ersten Tag braucht, gebunden an die Rolle und nicht an die Person: Mail und Kalender, das Intranet, die Kernsysteme dieser Funktion, die Ablagen dieses Teams. Weil es aus der Stellenrolle abgeleitet ist, kann es ohne Freigebenden im Weg vergeben werden, und genau das ist der Zweck: Es nimmt die Routinevergaben aus der Freigabewarteschlange, damit die Ausnahmen ordentlich gelesen werden. Zwei Regeln halten solche Pakete ehrlich. Bauen Sie sie aus dem, was die Stelle erfordert, und niemals durch Export der Zugriffe der Person, die sie zuletzt innehatte. Das kopiert jede angesammelte Zugabe gleich mit. Und geben Sie jedem Paket einen benannten Verantwortlichen und ein Überprüfungsdatum, denn ein Paket ohne Eigner wächst nur: Jeder Antrag, den man nicht ablehnen konnte, wird ihm hinzugefügt, und binnen zweier Jahre gewährt es weit mehr, als eine einzelne Stelle braucht.
Worin unterscheidet sich User Provisioning von einem Berechtigungsantrag?
Sie treffen sich in der Mitte und verantworten unterschiedliche Hälften. Der Berechtigungsantrag unter /de/templates/berechtigungsantrag-prozess beginnt bei einer Person, die bereits auf ihrer Stelle sitzt und ein weiteres System braucht: Sie stellt einen Antrag, Führungskraft und Systemverantwortlicher geben frei, der Zugriff wird bereitgestellt und später rezertifiziert. Die Berechtigungsvergabe für Mitarbeitende unter /de/templates/berechtigungsvergabe-mitarbeiter-prozess deckt denselben Antrag ab, wenn ein Eintritt oder Rollenwechsel in HR ihn auslöst und ein Rollenprofil ihn zuschneidet. Bei beiden geht es ums Entscheiden. Auf dieser Seite geht es ums Tun: die Identität anlegen, das Zugangsmittel ausgeben und die Mehr-Faktor-Authentifizierung einrichten, das Paket ableiten, Konten in jedem nachgelagerten System anlegen und die Berechtigungen aus den Zielsystemen zurücklesen, um zu prüfen, dass es die freigegebenen sind. Entwerfen Sie ein Antragsformular oder eine Freigabekette, nehmen Sie jene beiden. Bauen oder dokumentieren Sie die Provisionierungsmaschinerie dahinter, samt Identitäten für Externe und der Entzugshälfte eines internen Wechsels, nehmen Sie diese. Geht es um den Zugriff auf einen Datenbestand statt auf ein System, siehe /de/templates/datenzugriffsantrag-prozess.
Wie viel vom User Provisioning lässt sich wirklich automatisieren?
Mehr, als die meisten Häuser automatisiert haben, und nie alles. Systeme hinter Single Sign-on laufen ohne Ticket: Die Identität im Verzeichnis entsteht aus dem HR-Datensatz, das Paket der Rolle wird angewendet, die Gruppenzugehörigkeit folgt. Was die vollständige Abdeckung verhindert, ist die Systemlandschaft, die niemand geplant hat: das Entgeltsystem ohne Schnittstelle, das Laborgerät mit eigener lokaler Nutzerliste, das Partnerportal, in dem ein Konto durch die Antwort auf eine E-Mail entsteht. Diese brauchen eine Warteschlange mit benanntem Verantwortlichen und Zielzeit, und sie müssen aufgelistet sein, denn ein manuelles System, das nicht auf der Liste steht, wird beim Eintritt zu spät bereitgestellt und beim Austritt ganz vergessen. Führen Sie ein Verzeichnis darüber, welche Systeme angebunden sind und welche nicht, überarbeiten Sie es bei jeder Beschaffung, und behandeln Sie das Kürzen der manuellen Liste als das eigentliche Arbeitsprogramm. Die Vergabe zu automatisieren, ohne das Zurücklesen zu automatisieren, ist eine eigene Falle: Konnektoren scheitern lautlos, und deshalb liest der Verifizierungsschritt die Berechtigungen aus dem Zielsystem und nicht aus dem Ticket.
Wie stellt man Externen und anderen Nicht-Mitarbeitenden Zugriffe bereit?
Genauso wie Mitarbeitenden, nur sagt Ihnen keine vorgelagerte Quelle, dass es sie gibt. Auftragnehmer, Zeitarbeitskräfte, Prüfer, Techniker von Partnern, Praktikanten und technische Identitäten erscheinen selten im HR-System, deshalb müssen die beiden Angaben, die eine Identität überhaupt steuerbar machen, bewusst erfasst werden: ein benannter interner Sponsor, der für sie einsteht, und ein Ablaufdatum aus dem Vertrag oder der Beauftragung statt eines offenen Endes. Machen Sie den Ablauf automatisch: das Konto deaktiviert sich am Stichtag von selbst, und eine Verlängerung ist eine ausdrückliche Handlung des Sponsors mit einem neuen Enddatum. Übertragen Sie die Sponsorschaft, wenn ein Sponsor das Haus verlässt, denn eine Identität, deren Sponsor weg ist, ist genau das Konto, das niemand überprüft. Externe verdienen in der Regel auch engere Pakete und einen kürzeren Rezertifizierungstakt als Mitarbeitende, weil ihre Aufgabe schmaler ist und sie schneller wechseln. Die meisten verwaisten Konten, die eine Zugriffsüberprüfung zutage fördert, gehören jemandem, den das Haus nie beschäftigt hat.
Wo dieser Prozess einzuordnen ist
In den meisten Unternehmen folgt dieser Prozess auf Ablaufdiagramm zur Qualifikationsprüfung von Behandlern und übergibt an Berechtigungsentzug: Flussdiagramm zur Deprovisionierung.
Er ist ein Schritt in Zugriffssteuerung.
Schritt 1: Flussdiagramm User Provisioning (Eintritt, Wechsel, Austritt) Sie sind hier
Flussdiagramm für das User Provisioning: HR-Ereignis, Identität im Verzeichnis, Zugangsdaten und MFA, Berechtigungspaket der Rolle, Freigabe für privilegierte Rechte, nachgelagerte Konten, Verifizierung und Rezertifizierung.
Schritt 2: Ablaufdiagramm Berechtigungsantrag (Zugriffsrechte)
Ablaufdiagramm für den Berechtigungsantrag: rollenbasierter Antrag, Freigabe durch Führungskraft und Systemverantwortlichen, Funktionstrennung, Einrichtung und Rezertifizierung.
Schritt 3: Berechtigungsvergabe für Mitarbeiter: Eintritt und Rollenwechsel
Schritt 4: Berechtigungsentzug: Flussdiagramm zur Deprovisionierung