Berechtigungskonzept erstellen: Wer darf was – und wer prüft das?

Eine Mitarbeiterin wechselt vom Vertrieb in den Einkauf. Ihr neuer Zugang funktioniert. Die alten Exportrechte im CRM ebenfalls. Genau an solchen Übergängen zeigt sich, ob euer Berechtigungskonzept im Alltag greift.

Ein brauchbares Konzept beschreibt drei Dinge: welche Aufgaben welche Rechte erfordern, wer diese Rechte genehmigt und wie ihr die tatsächliche Vergabe prüft. Eine Liste von Gruppen ist nur ein Teil davon. Dieser Guide liefert dir eine Rollenmatrix und einen Ablauf, den du an einer Anwendung erproben kannst.

Beginne mit Aufgaben, nicht mit vorhandenen Gruppen

Wähle eine Anwendung mit klaren Verantwortlichen. Beschreibe zuerst die Tätigkeiten: Kundendaten lesen, Angebote bearbeiten, Stammdaten ändern oder Berechtigungen vergeben. Ordne ihnen die kleinsten passenden Rechte zu.

Der BSI-Baustein ORP.4 fordert unter A2 eine bedarfsgerechte Vergabe und den Entzug nicht mehr benötigter Rechte bei personellen Veränderungen. A3 behandelt den Abgleich der dokumentierten Rechte mit dem tatsächlichen Stand; A4 die Trennung unvereinbarer Aufgaben. Die folgenden Vorlagen sind unsere praktische Umsetzungshilfe, kein BSI-Formular.

Kopiere nicht einfach alle bestehenden Rechte in das Sollkonzept. Sonst erklärst du Altlasten zum Standard.

Eine Rollenmatrix, die sich entscheiden lässt

Fiktives Beispiel für ein CRM: Die genaue Zuordnung hängt von euren Aufgaben und der Anwendung ab.

Ergänze für jede Rolle, welche Rechte ausdrücklich nicht dazugehören. Ein Datenexport kann beispielsweise eine andere Wirkung haben als das Lesen einzelner Datensätze. Prüfe außerdem Konflikte: Darf dieselbe Person einen kritischen Vorgang auslösen und dessen Freigabe erteilen?

Für Ausnahmen brauchst du eine Begründung, eine entscheidende Rolle und einen nächsten Prüfanlass. „Brauchen wir vielleicht später“ ist keine belastbare Aufgabenbeschreibung.

Eintritt, Wechsel und Austritt sauber übergeben

Beim Eintritt beginnt der Ablauf mit der bestätigten Aufgabe. Die zuständige Fachrolle beantragt die passende Rolle, eine befugte Person entscheidet und der IT-Betrieb setzt sie um. Der Nachweis verbindet Antrag, Freigabe und tatsächlich eingerichteten Zugriff.

Beim Wechsel prüfst du beide Seiten: neue Rechte hinzufügen und alte Rechte entfernen. Halte ausdrücklich fest, ob Übergangsrechte erforderlich sind und wann sie enden. Ein abgeschlossenes Onboarding-Ticket belegt den Entzug alter Rechte nicht.

Beim Austritt müssen die Beteiligten wissen, wann Zugänge zu sperren sind. Beziehe neben dem zentralen Benutzerkonto auch lokale Konten, externe Dienste und administrative Zugänge ein. Technische Konten sind gesondert zu prüfen: Sie können weiter benötigt werden, brauchen aber eine zuständige Person und gegebenenfalls einen Wechsel der Zugangsmittel.

Prüfe den Istzustand – nicht nur die letzte Freigabe

Eine Rezertifizierung ist die erneute fachliche Prüfung bestehender Rechte. Lege ihren Umfang und Rhythmus anhand eurer Risiken fest. Ein festes Intervall allein ersetzt keine Prüfung nach einem Rollenwechsel oder einer wesentlichen Änderung.

Fordere den tatsächlichen Rechtebestand aus der Anwendung an. Vergleiche ihn mit Aufgabe, Rollenmatrix und genehmigten Ausnahmen. Auch direkt vergebene Einzelrechte und verschachtelte Gruppen können relevant sein.

Die Prüfung ist erst nachvollziehbar abgeschlossen, wenn die Entscheidung umgesetzt oder eine offene Ausnahme bewusst weitergeführt wird. Eine versendete Aufforderung zum Rechteentzug genügt dafür nicht.

Trenne Steuerung und technische Durchsetzung

Ein Identity- oder Berechtigungsmanagement-System setzt Zugriffe technisch um. Im ISMS hältst du Vorgaben, Verantwortlichkeiten, Prüfungen und offene Maßnahmen zusammen. Beides muss zusammenpassen.

Für einen ersten Test reicht eine Anwendung: Nimm einen echten Rollenwechsel, vergleiche Soll und Ist und führe eine notwendige Änderung bis zum technischen Nachweis. Danach siehst du, ob die Lücke in der Rollenbeschreibung, in der Übergabe oder in der Umsetzung liegt.

Wenn ihr diesen Ablauf in Kopexa besprechen wollt, bringt genau diesen Prüffall mit. Relevant ist, wie Verantwortung, Maßnahme und Nachweis zusammenbleiben; die Rechtevergabe im Zielsystem bleibt eine eigene technische Aufgabe.