Rollen- und Rechtekonzept: Wer darf was in Ihrer Software?

Warum hängt eine Rolle an der Aufgabe und nicht an der Person?

In gewachsenen Systemen werden Rechte fast immer anlassbezogen vergeben: Frau Berger braucht kurz Zugriff auf die Lohnbuchhaltung, also bekommt sie ihn. Zwei Jahre später hat sie drei Zuständigkeiten abgegeben und trotzdem jedes Häkchen behalten. Niemand traut sich, etwas wegzunehmen, weil niemand mehr weiß, warum es gesetzt wurde.

Ein Rollenkonzept dreht diese Logik um. Es beschreibt Tätigkeiten: „Sachbearbeitung Lohn“, „Prüfung Jahresabschluss“, „Kanzleileitung“. Menschen werden diesen Rollen zugeordnet und wieder entzogen. Wechselt eine Zuständigkeit, ändert sich genau eine Zuweisung statt eines Dutzends verstreuter Einzelrechte.

Der Effekt zeigt sich spätestens beim Austritt. Wird ein Konto deaktiviert, verschwinden mit den Rollen auch sämtliche Berechtigungen. Bei personenbezogen vergebenen Einzelrechten bleiben regelmäßig Reste in Nebensystemen liegen, die erst bei einer Prüfung auffallen.

• Benennen Sie Rollen nach der Tätigkeit, nie nach einem Namen oder einer Abteilungsbezeichnung, die sich alle zwei Jahre ändert.
• Halten Sie die Zahl der Rollen klein: zehn bis fünfzehn gut geschnittene Rollen sind in mittelständischen Systemen üblich.
• Erlauben Sie mehrere Rollen pro Person statt für jede Kombination eine neue Rolle anzulegen.
• Dokumentieren Sie zu jeder Rolle in einem Satz, welche fachliche Aufgabe sie abdeckt.

Rollenbasiert oder attributbasiert — was passt zu welchem System?

Die rollenbasierte Vergabe knüpft Rechte an eine feste Rollenliste. Sie ist leicht zu verstehen, gut prüfbar und für die allermeisten Fachanwendungen im Mittelstand ausreichend. Ihre Grenze erreicht sie, sobald Rechte von Eigenschaften des Datensatzes abhängen sollen.

Die attributbasierte Vergabe entscheidet zur Laufzeit anhand von Merkmalen: Standort der Anwenderin, Vertraulichkeitsstufe eines Dokuments, Wert eines Auftrags, Uhrzeit. Ein Hersteller von Medizintechnik kann so festlegen, dass Prüfprotokolle einer laufenden Zulassung nur der zugeordneten Projektgruppe offenstehen, ohne für jedes Projekt eine eigene Rolle zu bauen.

Beide Modelle schließen sich nicht aus. Die tragfähigste Variante ist meist eine Rollenbasis für die grobe Einteilung, ergänzt um wenige Attributregeln für die Fälle, in denen der Datensatz selbst entscheidet. Wer von Anfang an alles über Attribute lösen will, baut ein Regelwerk, das nach einem Jahr niemand mehr überblickt.

Vererbung spart Pflege und erzeugt blinde Flecken

Hierarchien sind verlockend: Die Teamleitung erbt alles vom Team, die Bereichsleitung alles von den Teams. Das spart Pflegeaufwand, führt aber dazu, dass ganz oben Personen sitzen, die faktisch jedes Recht im System besitzen — häufig ohne dass es jemand beabsichtigt hätte.

Begrenzen Sie Vererbung deshalb auf zwei Ebenen und definieren Sie ausdrücklich, welche Rechte nicht vererbt werden. Personaldaten, Gehaltsbestandteile und Löschfunktionen gehören typischerweise dazu. Prüfen Sie außerdem, wie sich Verbote verhalten: Gewinnt ein ausdrückliches Verbot gegen ein geerbtes Recht, oder umgekehrt? Diese Frage muss beantwortet sein, bevor jemand sie im Betrieb entdeckt.

Reicht es, ganze Bildschirmmasken freizugeben?

Masken freizuschalten ist die schnellste Umsetzung und in vielen Projekten die erste Näherung. Sie trägt so lange, wie eine Maske genau einer Zuständigkeit entspricht. Sobald mehrere Rollen dieselbe Ansicht brauchen, aber unterschiedlich viel sehen dürfen, wird es unsauber.

Trennen Sie deshalb früh zwischen Sichtbarkeit und Bearbeitbarkeit. Eine Steuerfachangestellte darf einen Mandantenstammsatz vollständig sehen, aber die Bankverbindung nicht ändern. Technisch sind das zwei verschiedene Prüfungen, und sie müssen serverseitig erfolgen — ein ausgegrautes Eingabefeld ist keine Berechtigung, sondern eine Anzeige.

• Funktionsebene: Darf diese Rolle die Funktion überhaupt aufrufen, etwa „Rechnung stornieren“?
• Datensatzebene: Welche Datensätze sieht sie — nur die eigene Niederlassung, nur eigene Vorgänge, alles?
• Feldebene: Welche einzelnen Felder sind lesbar, welche änderbar, welche gar nicht sichtbar?
• Exportebene: Darf sie Daten aus dem System herausschreiben, und wenn ja, in welchem Umfang?

Die Exportebene wird regelmäßig vergessen. Eine Rolle, die eine Liste nur lesen darf, aber eine unbegrenzte Tabellenausgabe anstoßen kann, hat faktisch Vollzugriff auf diese Daten — inklusive der Möglichkeit, sie außerhalb des Systems weiterzureichen.

Was passiert bei Urlaub, Krankheit und Zuständigkeitswechsel?

Vertretung ist der Punkt, an dem gut gemeinte Konzepte im Alltag aufgeweicht werden. Wenn die Freigabe drei Wochen liegen bleibt, weil die zuständige Person im Urlaub ist, entstehen genau die Umgehungen, die man verhindern wollte: geteilte Passwörter, Freigaben über Zuruf, ein Sammelkonto.

Bauen Sie Vertretung deshalb als reguläre Funktion ein, nicht als Ausnahme. Eine Vertretung wird befristet erteilt, ist im System sichtbar, endet automatisch und erscheint in jedem Protokolleintrag als solche. Wer eine Freigabe in Vertretung erteilt hat, muss zwei Jahre später nachvollziehbar sein.

Für dauerhafte Wechsel gilt eine andere Regel: Beim Übergang in eine neue Aufgabe wird die alte Rolle entzogen, nicht ergänzt. Der häufigste Weg zu überprivilegierten Konten ist die interne Beförderung, bei der die alten Rechte „vorsichtshalber“ bleiben.

Wie bilden Sie ein Vier-Augen-Prinzip technisch ab?

Ein Vier-Augen-Prinzip verlangt, dass die vorbereitende und die freigebende Person verschieden sind. Technisch braucht es dafür drei Dinge: einen Zustand „zur Freigabe vorgelegt“, eine Prüfung, dass der Freigebende nicht der Ersteller ist, und eine unveränderliche Aufzeichnung beider Schritte.

Klären Sie fachlich, welche Vorgänge das überhaupt brauchen. Zahlungsanweisungen, Änderungen an Bankverbindungen, Preisfreigaben und Stornierungen oberhalb eines Betrags sind typische Kandidaten. Alles andere mit einer Freigabestufe zu belegen, verlangsamt den Betrieb, ohne Risiko zu senken — und erzeugt Freigaben, die nur noch durchgewinkt werden.

Eine Freigabe, die niemand ernsthaft prüft, ist keine Kontrolle. Sie ist nur ein zusätzlicher Klick mit Protokolleintrag.

Warum müssen Rechteänderungen protokolliert und regelmäßig überprüft werden?

Ein Rechtesystem ohne Protokoll beantwortet die wichtigste Frage nicht: Wer hat wann wem welches Recht gegeben? Protokollieren Sie deshalb nicht nur fachliche Vorgänge, sondern die Verwaltung der Rechte selbst — mit Zeitstempel, auslösender Person, altem und neuem Zustand. Diese Einträge dürfen im System nicht änderbar sein.

Dazu kommt die Rezertifizierung: eine wiederkehrende Prüfung, ob die vergebenen Rollen noch zur tatsächlichen Aufgabe passen. Ein bis zwei Durchläufe im Jahr reichen in mittelständischen Organisationen. Wirksam wird sie erst, wenn die Fachbereichsleitung bestätigt und nicht die IT — nur der Fachbereich weiß, wer welche Aufgabe wirklich noch hat.

• Erzeugen Sie eine Liste je Fachbereich statt einer Gesamtliste, die niemand durcharbeitet.
• Fragen Sie nach aktivem Bestätigen: Nicht bestätigte Rechte laufen nach einer Frist aus.
• Nehmen Sie inaktive Konten mit auf — Konten ohne Anmeldung seit sechs Monaten gehören auf den Prüfstand.
• Halten Sie das Ergebnis fest, damit die nächste Prüfung an einer Ausgangslage ansetzen kann.

Wie binden Sie Verzeichnisdienst und Single Sign-on an?

In den meisten Unternehmen existiert bereits eine Benutzerverwaltung, häufig ein Verzeichnisdienst wie Active Directory oder Entra ID. Eine neue Fachanwendung sollte daran andocken, statt eine zweite Nutzerliste zu führen. Der Gewinn liegt weniger in der Bequemlichkeit als in der Austrittslogik: Ein gesperrtes zentrales Konto sperrt sofort alle angebundenen Systeme.

Für die Anmeldung kommen üblicherweise OpenID Connect oder SAML zum Einsatz, ergänzt um Gruppen aus dem Verzeichnis, die auf Rollen der Anwendung abgebildet werden. Legen Sie diese Zuordnung als Tabelle an und pflegen Sie sie an einer Stelle. Wer Gruppennamen im Programmcode verstreut, hat bei der nächsten Umorganisation ein Entwicklungsticket statt einer Konfigurationsänderung.

Planen Sie außerdem einen Notzugang. Wenn der Identitätsanbieter ausfällt, brauchen Sie mindestens ein lokales Administrationskonto mit starkem zweitem Faktor, dessen Nutzung besonders protokolliert wird. Nach unserer Projekterfahrung wird dieser Fall gerne verschoben — und fällt dann an einem Freitagnachmittag auf.

Wie viel Projektzeit kostet ein sauberes Rechtekonzept?

Für eine mittelgroße Fachanwendung veranschlagen wir zwei bis fünf Workshoptage mit den Fachbereichen, dazu ein bis zwei Tage für die schriftliche Fassung und die Abstimmung. Ergebnis sind eine Rollenliste, eine Matrix aus Rollen und Funktionen, die Regeln für Sichtbarkeit auf Datensatzebene sowie die Festlegungen zu Vertretung, Freigaben und Protokoll.

Diese Tage stehen vor der Entwicklung, nicht daneben. Der Grund ist technisch: Wer Datensätze mandanten- oder bereichsbezogen filtern muss, greift damit in jede Abfrage, jede Liste und jede Auswertung ein. Nachträglich betrifft das nicht ein Modul, sondern die gesamte Datenzugriffsschicht — bei einem Projekt im Bereich 40.000 bis 80.000 € kann die Umstellung leicht einen fünfstelligen Nachschlag bedeuten.

Ein guter Test für die Reife des Konzepts ist eine simple Frage an das Projektteam: Nennen Sie fünf konkrete Personen aus dem Fachbereich und sagen Sie, welche Rollen sie am ersten Produktivtag bekommen. Wenn diese Antwort ohne Rückfrage gelingt, kann die Entwicklung starten.

Planen Sie zusätzlich einen Nachlauf ein. Etwa sechs bis acht Wochen nach dem Produktivstart lohnt ein halber Tag, um die tatsächlich genutzten Rechte mit dem Konzept abzugleichen. Bis dahin hat der Alltag gezeigt, wo eine Rolle zu eng geschnitten war und wo eine Freigabestufe nur bremst — beides lässt sich in dieser Phase noch günstig korrigieren, weil die Datenzugriffe frisch im Kopf sind.