Benutzerverwaltung im ERP: Eintritt, Wechsel, Austritt, Rechte-Review

Der Baustein ORP.4 nennt als eigene Gefährdungslage, dass der IT-Betrieb von personellen Veränderungen zu spät erfährt und Konten ausgeschiedener Mitarbeitender weiterlaufen; ebenso sammeln umgesetzte Mitarbeitende ihre alten Rechte an (Abschnitt 2.1, Stand Februar 2023). Dagegen hilft kein einzelner Schalter, sondern ein Verfahren mit drei Auslösern – Eintritt, Wechsel, Austritt – und einer wiederkehrenden Kontrolle des tatsächlichen Standes. Es folgt der Methode des Bundesamts für Sicherheit in der Informationstechnik (BSI) und lässt sich in Deutschland, Österreich und der Schweiz gleich anwenden.

Was Sie vorab brauchen

• ein Verzeichnis aller Zugänge zum ERP: persönliche Kennungen, Gruppen- und Rollenkonten, technische Konten für Schnittstellen wie Shop oder Bank, dazu Token
• die Rollen- und Rechteübersicht aus dem System als Tabelle mit Exportdatum
• die Zuordnung der Rollen zu Personen: wer Rechte genehmigt und wer sie einrichtet (der Baustein trennt Benutzende, Genehmigende, Fachverantwortliche und IT-Betrieb)
• ein Antragsformular mit Name, Organisationseinheit, Tätigkeit, benötigten Rechten, Dauer und Zustimmung der vorgesetzten Person (ORP.4.M1)
• die Meldung der Personalstelle an die für Rechte zuständige Stelle bei Eintritt, Wechsel und Austritt

Der Baustein trennt Zugang (Nutzung von IT-Systemen), Zugriff (Nutzung von Daten) und Zutritt (Betreten von Räumen); hier geht es um Konten und Rechte im System (Umsetzungshinweis ORP.4, Abschnitt 1). Für Ihren Betrieb verbindlich werden diese Anforderungen durch Vertrag oder eigene Richtlinie; der Grundschutz selbst ist Methode und Empfehlung.

Schritt für Schritt: Konten und Rechte pflegen

Schritt 1: Kontenverzeichnis anlegen

Tragen Sie jede Kennung mit Inhaber, Organisationseinheit, Rechteprofil, Grund der Einrichtung und Befristung ein (Inhalt nach Umsetzungshinweis M3). Bei Gruppen-, System- und Schnittstellenkonten steht statt eines Inhabers eine namentlich verantwortliche Person; M15 verlangt sie. Ende: Jede Kennung hat eine Zeile und eine verantwortliche Person.

Schritt 2: Zugang beantragen und genehmigen lassen

Zu jedem neuen Zugang gehört ein Antrag mit Funktion, benötigten Rechten und Befristung. Rechte über dem Standard dürfen nur nach Begründung und Prüfung vergeben werden (ORP.4.A2). Wer genehmigt, darf sich nicht selbst Rechte genehmigen (M2). Ende: Der Antrag trägt Datum, Begründung und Namen der genehmigenden Person.

Schritt 3: Konto über eine administrative Rolle einrichten

Kennungen und Berechtigungen dürfen nur über separate administrative Rollen eingerichtet werden (ORP.4.A1, A2). Vergeben Sie ein Standard-Rechteprofil nach Aufgabe (ORP.4.A16); das Erstpasswort wird bei der ersten Anmeldung gewechselt (M1). Kennungen mit weitreichenden Berechtigungen sollten mit Mehr-Faktor-Authentisierung geschützt werden (ORP.4.A10; bei erhöhtem Schutzbedarf ORP.4.A21). Ende: Die Anmeldung erfolgt mit eigenem Konto, das Einrichtungsdatum steht im Verzeichnis.

Schritt 4: Funktionswechsel abbilden

Bei personellen Veränderungen müssen die nicht mehr benötigten Kennungen und Berechtigungen entfernt werden (ORP.4.A2). Arbeiten Sie den Entzug vor der Vergabe der neuen Rechte ab; ORP.4.A4 verlangt, unvereinbare Aufgaben im Berechtigungsmanagement zu trennen. Die Paare für Einkauf, Lager und Buchhaltung stehen in der Funktionstrennung-Matrix. Ende: Im Verzeichnis stehen nur die neuen Rechte, das Entzugsdatum ist notiert.

Schritt 5: Austritt abwickeln

Arbeiten Sie am letzten Arbeitstag die Austritts-Checkliste unten ab. M2 nennt den Rahmen: nicht mehr benötigte Kennungen innerhalb einer definierten Zeit sperren und nach einer definierten Wartezeit vollständig löschen; als Weg empfiehlt er, zuerst zu deaktivieren – etwa einen Monat – und die Kennung mittelfristig, zum Beispiel innerhalb von drei Monaten, aus dem Produktivsystem zu entfernen. Der Vorgang “Weggang von Mitarbeitern” (M15) umfasst das Löschen aller Rollenzuordnungen und Berechtigungen sowie die Rückgabe von Authentisierungstoken. Ende: Jeder Punkt hat Datum und abzeichnende Person.

Schritt 6: Technische Konten und Token nachhalten

Technische Kennungen gehören keiner Person, brauchen aber eine verantwortliche (M15). Für Kennungen von technischen Konten, Dienstkonten und Schnittstellen plant den Passwortwechsel sorgfältig und stimmt ihn mit dem Anwendungsverantwortlichen ab; vordefinierte Kennungen und Standardpasswörter müssen geändert werden (ORP.4.A23). Ausgabe und Entzug von Token und Chipkarten werden dokumentiert (ORP.4.A7). Ende: Für jede Schnittstelle stehen verantwortliche Person, Zweck und letzter Wechsel im Verzeichnis.

Schritt 7: Rechte-Review durchführen

Bei längeren Abwesenheiten sollten berechtigte Personen vorübergehend gesperrt werden (ORP.4.A5 bis A7), mindestens mit weitreichenden Berechtigungen (M6); die Rechte bleiben während der Sperre erhalten (M15). Prüfen Sie die Dokumentation daraufhin, ob sie den tatsächlichen Stand der Rechtevergabe wiedergibt und die Rechte noch zu den aktuellen Aufgaben passen (ORP.4.A3); der Baustein nennt keinen Zeitraum, M3 empfiehlt mindestens alle sechs Monate und zusätzlich eine Prüfung nach System- oder Anwendungsupdates. Nutzen Sie das Prüfblatt unten; ein MUSS ist unbedingt zu erfüllen, bei einem SOLLTE ist die Abweichung zu begründen. Schützen Sie die Dokumentation vor unberechtigtem Zugriff, beziehen Sie sie in die Datensicherung ein und halten Sie fest, welche Kennung von wann bis wann welche Rechte hatte (ORP.4.A3, M2). Ende: Die Prüfrunde ist datiert, die abgezeichnete Fassung liegt ab; wo die Nachweise liegen, beschreibt das Betriebshandbuch fürs ERP.

So prüfen Sie das Ergebnis

Drei Gegenproben zeigen, ob das Verfahren trägt:

1. Vollständigkeit: Jede Kennung im Verzeichnis existiert im System und umgekehrt; M15 nennt als Prüfpunkt Berechtigungen, die direkt auf den Zielsystemen vergeben wurden.
2. Trennung: ORP.4.A14 (Standard-Anforderung) verlangt, in angemessenen Zeitabständen zu prüfen, ob sich Benutzende nach der Aufgabenerfüllung abmelden und ob nicht mehrere unter einer Kennung arbeiten; der Umsetzungshinweis M14 nennt dafür ausgewertete Protokolle oder Stichproben.
3. Austritt: Ein Protokolltreffer ist kein Nachweis für ein aktives Konto. Prüfen Sie, ob nach dem Austrittsdatum noch eine Anmeldung gelingt – auch mit dem ursprünglich ausgegebenen Erstpasswort.

Das Prüfblatt für den Rechte-Review

Eine Seite je Prüfrunde: Spalte 1 die Prüffrage, Spalte 2 die Bedingung für bestanden, Spalte 3 der Nachweis. Beispielannahme für 30 Mitarbeitende: 24 persönliche Kennungen, drei Gruppenkonten, fünf Schnittstellenkonten, zwei Administrationskonten und drei ausgegebene Token – 24 + 3 + 5 + 2 + 3 ergibt 37 Zeilen, denn hier steht jeder Zugang, auch jedes Token, in einer eigenen Zeile des Verzeichnisses.

Prüffrage	Bestanden, wenn	Nachweis
Zuordnung der Konten	jede Kennung hat einen Inhaber oder eine verantwortliche Person, auch Gruppen- und Schnittstellenkonten	Verzeichnis, Stand des Exports
Rechte nach Bedarf	je Person nur Rechte der aktuellen Aufgabe (Need-to-know, ORP.4.A2)	Rechtebericht je Kennung
Ausnahmen begründet	jede Berechtigung über dem Standard trägt Begründung und Genehmigung	Antrag mit Datum und Name
Inaktive Kennungen	Kennungen ohne Nutzung über den festgelegten Zeitraum sind deaktiviert (ORP.4.A1)	Anmelde- oder Sperrprotokoll
Austritt und Token	ausgeschiedene Personen sind aus Rollen und Gruppen entfernt, zurückgegebene Token entzogen (ORP.4.A7)	Austritts-Checkliste
Technische Konten	je Schnittstellenkonto stehen verantwortliche Person, Zweck und geplanter Passwortwechsel	Verzeichnis, Wechselplan
Funktionstrennung	keine Kennung vereint unvereinbare Aufgaben (ORP.4.A4)	Funktionstrennung-Matrix

Ein Prüfintervall schreibt der Baustein nicht vor; M3 empfiehlt mindestens alle sechs Monate. Nach redaktioneller Einschätzung gehören weitreichende Rechte, Administrations- und Schnittstellenkonten in jeden Prüflauf, Leserechte ohne Schreibzugriff dürfen seltener dran sein.

Die Austritts-Checkliste

Die Punkte folgen dem Vorgang “Weggang von Mitarbeitern” (Umsetzungshinweis ORP.4.M15) und dem Entzug nach ORP.4.M2. Jeder Punkt bekommt Datum und Kürzel.

Punkt	Erledigt, wenn
Kennungen sperren	alle Kennungen der Person, nicht nur die Hauptkennung, sind am letzten Arbeitstag gesperrt
Rollen und Vertretungen entziehen	die Person ist aus allen Rollenzuweisungen, Gruppen und Vertretungen entfernt
Zugänge außerhalb des ERP	Shop, Zeiterfassung, Dokumentenablage und Mail sind nach derselben Liste behandelt
Geteilte und technische Kennungen	Passwörter, die die Person kannte, sind geändert; der Wechsel bei Schnittstellen ist mit der Anwendungsverantwortlichen abgestimmt (ORP.4.A23)
Token, Zertifikat, Chipkarte	ausgehändigte Mittel sind zurückgenommen, Ausgabe und Entzug dokumentiert (ORP.4.A7)
Betreute Schnittstellen	für jedes technische Konto, das die Person verantwortet hat, ist eine neue verantwortliche Person eingetragen
Rechtehistorie und Löschtermin	festgehalten ist, welche Kennung von wann bis wann welche Rechte hatte (M2), und ein Termin für die Löschung steht fest (Beispiel drei Monate)
Meldung	die für Rechte zuständige Stelle und die Personalstelle sind informiert (M2)

Wenn etwas nicht klappt

Symptom	Mögliche Ursache	Umgang
Eine ausgeschiedene Person kommt noch ins ERP	Sperre aufgehoben, zweites Konto oder geteilte Kennung	alle Kennungen der Person prüfen, Anmeldeprotokoll ansehen, geteilte Kennung auflösen
Nach dem Wechsel bestehen alte Rechte fort	der Entzugsschritt fehlt im Ablauf	Entzug mit Datum in den Antrag aufnehmen und gegen das Verzeichnis prüfen
Eine Schnittstelle fällt nach einem Passwortwechsel aus	Wechsel nicht mit dem Anwendungsverantwortlichen abgestimmt (ORP.4.A23)	Wechselfenster absprechen, technisches Konto samt verantwortlicher Person dokumentieren
Im Review zeigt sich keine Abweichung	Geprüft wurde die Rollendefinition gegen sich selbst	je Kennung die wirksamen Rechte aus dem System ablesen
Rechte sind nicht trennbar	Rollenmodell zu grob, Rechte hängen an Feldern	Rollen neu zuschneiden, siehe Rollen- und Rechtekonzept
Anträge kommen am Verfahren vorbei	Antragspflicht nur mündlich vereinbart	Genehmigungsweg schriftlich festlegen, Abweichungen im Review vermerken

Wann Sie Hilfe holen sollten

Holen Sie den Systembetreuer oder Herstellersupport, wenn die Rechteauskunft Ihres ERP keine Zuordnung Person zu wirksamem Recht hergibt, sondern nur Rollendefinitionen; ohne diese Auskunft bleibt das Prüfblatt eine Papierübung. Mitbestimmung, Beschäftigtendatenschutz und Aufbewahrung beurteilt nicht der IT-Grundschutz, sondern das Recht des jeweiligen Landes; dafür sind Personal- und Rechtsabteilung zuständig. Für den Zugriff von Automaten und KI-Agenten gilt dieselbe Logik, ergänzt um eigene Konten und Freigaben: KI-Agenten absichern. Müssen Konten unter Zeitdruck gesperrt werden, hilft der Ablauf bei Cyberangriff auf das ERP; für die technische Basis darüber hinaus die ERP-Sicherheitsbasis.