Rollenmodell für Individualsoftware: Rechte schneiden und belegen

Ein Rollenmodell für Individualsoftware entscheidet, wer in einer neuen Fachanwendung welche Akte öffnen, ändern und freigeben darf. Wird es erst zur Abnahme aufgeschrieben, ist die Entscheidung längst gefallen, nur hat sie niemand getroffen. Woran ein Berechtigungskonzept in der Praxis scheitert und wie es prüffest entsteht, ordnet dieser Text ein.
Zwei Beschäftigte stecken je einen Schlüssel in ein Aktenschrankschloss mit zwei Schlüssellöchern. Sinnbild für das Rollenmodell in Individualsoftware, das einen Vorgang an zwei Befugnisse bindet.
© KI-generiert (TenMedia)

Was ein Rollenmodell in Individualsoftware festlegt

Die Hamburger Datenschutzaufsicht führt Zugriffe von Beschäftigten auf Daten, die sie nicht brauchen, als eigene Ursache. Im 34. Tätigkeitsbericht stehen dafür 21 Meldungen für 2025, nach 13 im Jahr davor.

Ein Rollenmodell für Individualsoftware legt fest, welche Nutzergruppen in einer maßgeschneiderten Anwendung welche Funktionen und Daten sehen, bearbeiten, freigeben oder löschen dürfen. Es bündelt einzelne Rechte zu wenigen Profilen, bindet diese Profile an Aufgaben statt an Personen und hält nachvollziehbar fest, wer zu welchem Zeitpunkt worauf zugreifen konnte. Ein Berechtigungskonzept beschreibt dieselbe Sache in Vertragssprache und ist das Dokument, das eine Prüfung verlangt.

Das Rollen- und Rechtekonzept entlang der Aufgabe

Der häufigste Entwurfsfehler ist unscheinbar. Die Rollen folgen dem Organigramm, also Sachgebiet 1, Sachgebiet 2, Amtsleitung, jeweils mit den Rechten, die die Stelle gerade braucht. Das ist keine Frage des organisationsweiten Berechtigungsmanagements, das Rechte vergibt, prüft und wieder entzieht, sondern eine Entwurfsentscheidung in der Anwendung selbst. Der Schnitt entscheidet, ob das Rollenmodell die nächste Umorganisation übersteht. Wer Rechnungen erfasst, behält dieses Recht auch nach einem Wechsel des Sachgebiets, während eine Rolle namens „Sachgebiet 2” danach niemandem mehr zuzuordnen ist. Wie sich ein solcher Schnitt später belegen lässt, klärt der Abschnitt zur Rekonstruktion des Rechtestands.

Wenn die Vertretung den Rollenschnitt sprengt

Die Vertretung ist der Fall, an dem saubere Rollenmodelle scheitern. Fällt eine Person aus, braucht jemand anderes deren Rechte, und der schnellste Weg ist die dauerhafte Erweiterung der eigenen Rolle. So entstehen über Jahre Konten mit Rechten, die niemand mehr begründen kann, ein Effekt, den das IT-Sicherheitsmanagement als Privilege Creep beschreibt. Eine Anwendung, die befristete Zuweisungen kennt, löst das ohne Zusatzarbeit, weil das Recht von selbst verfällt.

Diese Fälle werden vor der Umsetzung entschieden, nicht im Betrieb:

Warum sollte Software Rechte statt Rollen prüfen?

Weil eine Rolle ein Bündel ist und ein Recht eine einzelne Erlaubnis. Fragt die Anwendung im Quellcode ab, ob die angemeldete Person die Rolle „Teamleitung” trägt, ist jede spätere Änderung ein Eingriff in die Software. Fragt sie ab, ob diese Person das Recht „Rechnung freigeben” besitzt, genügt eine Anpassung der Profile. Beide Varianten sehen in der Oberfläche gleich aus, weshalb der Unterschied bei der Abnahme regelmäßig durchgeht. Ein Rollen- und Rechtekonzept auf Papier sagt darüber nichts, es beschreibt das Ergebnis und nicht den Weg dorthin.

Rollennamen im Code überleben keine Umorganisation

Die Entscheidung wirkt akademisch und bestimmt die Wartungskosten der nächsten fünf Jahre. Eine Verwaltung, die eine Aufgabe von der Teamleitung auf die Sachbearbeitung verlagert, ändert im ersten Fall den Quellcode und lässt neu testen und abnehmen. Im zweiten Fall setzt eine berechtigte Person ein Häkchen. Rechte im Code, Rollen in der Konfiguration ist deshalb die Entscheidung, die einen datenschutzkonformen Entwurf nach Privacy by Design überhaupt umsetzbar macht, weil jede Verfeinerung sonst einen Änderungsauftrag braucht.

Vier Fragen machen den Unterschied im Abnahmetest sichtbar:

❓ Entstehen neue Profile in der Oberfläche oder braucht es eine Softwareänderung?
❓ Lässt sich ein einzelnes Recht entziehen, ohne ein ganzes Profil zu tauschen?
❓ Ist die Bezeichnung eines Profils frei änderbar, ohne dass Funktionen ausfallen?
❓ Können zwei Organisationseinheiten dasselbe Recht unterschiedlich bündeln?

Mandantentrennung von Anfang an mitdenken

Sobald mehrere Ämter, Kommunen oder Tochtergesellschaften dieselbe Anwendung nutzen, kommt eine zweite Ebene hinzu. Das Recht allein genügt dann nicht, es braucht die Angabe, auf welchen Datenbestand es sich bezieht. Wird diese Trennung erst nachträglich eingebaut, betrifft sie jede Abfrage und jeden Bericht, weshalb sie zum Datenmodell gehört und nicht zur Oberfläche. Eine nachgerüstete Mandantentrennung ist der teuerste Posten in einem sonst gesunden Rollenmodell, weil sie an keiner Stelle abgekürzt werden kann.

Funktionstrennung und Nachweis im Berechtigungskonzept

Ein Berechtigungskonzept regelt nicht nur, wer etwas darf, sondern auch, welche Aufgaben nie in einer Hand liegen. Der BSI-Baustein ORP.4 verlangt in seiner Basis-Anforderung ORP.4.A4 die Trennung unvereinbarer Aufgaben und Funktionen, und in ORP.4.A2 die Vergabe nach dem Prinzip der geringsten Berechtigungen. Beide Anforderungen richten sich an die Organisation, treffen aber die Software, denn ohne technische Sperre bleibt die Trennung eine Absprache.

Welche Funktionen dürfen nicht in einer Rolle liegen?

Das BSI führt das an einem Abrechnungssystem für Reisekosten vor. Sechs Funktionen sind dort nötig, und drei Kombinationen daraus sind ausgeschlossen: Die Administration darf sich nicht selbst kontrollieren, die anordnungsbefugte Person darf sich nicht selbst prüfen, und Sachbearbeitung samt Anordnungsbefugnis heben zusammen das Vier-Augen-Prinzip auf. Welche Kombinationen unvereinbar sind, entscheidet die Organisation, nicht die Software, denn nur sie kennt ihre Geschäftsverteilung. Ein Rollenmodell für Individualsoftware setzt diese Sperren technisch um und lehnt eine verbotene Zuweisung schon bei der Eingabe ab, statt sich auf Aufmerksamkeit zu verlassen.

Den Rechtestand zu einem Stichtag rekonstruieren

Ein Rollenmodell wird belegbar, wenn die Anwendung nicht nur den heutigen Zustand kennt, sondern jeden früheren. Wer Zuweisungen überschreibt, verliert genau die Auskunft, die im Streitfall und bei jeder Prüfung nach IT-Compliance zählt, nämlich welches Profil an einem bestimmten Tag gegolten hat. Technisch heißt das, Rechteänderungen als Ereignisse zu speichern statt als Zustand, und diese Entscheidung fällt beim Datenmodell. Nachträglich lässt sie sich nicht herstellen, weil die Historie der vergangenen Jahre dann fehlt.

Was die Anwendung dafür dauerhaft vorhalten muss:

Das Rollenmodell für Individualsoftware ausschreiben

Bei einer Vergabe entscheidet sich früh, ob das Rollenmodell für Individualsoftware später trägt. Die Leistungsbeschreibung muss beides enthalten, die fachlichen Vorgaben aus der Organisation und die technischen Eigenschaften, die der Auftragnehmer liefert. Fehlt der zweite Teil, ist die Anwendung formal abnahmefähig und im Betrieb dennoch starr, und jede Änderung am Rechteschnitt wird beauftragungspflichtig.

Das Rollen- und Rechtekonzept in der Leistungsbeschreibung

Die fachliche Seite bleibt Aufgabe der Vergabestelle, weil nur sie die Geschäftsverteilung und die unvereinbaren Funktionen kennt. Gefordert wird deshalb kein fertiges Rollen- und Rechtekonzept, sondern die belegte Fähigkeit der Software, eines abzubilden und später zu ändern. Das Berechtigungskonzept entsteht danach im Projekt. Getrennt davon zu beschreiben ist die Anbindung der Fachanwendung an ein IAM, denn sie regelt die Herkunft der Konten, nicht die Rechte daran.

Diese Punkte gehören in die Anforderungen:

TenMedia entwickelt Individualsoftware für Behörden und KRITIS-Betreiber und legt das Rollen- und Rechtekonzept in der Anforderungsphase fest, nicht nach der Abnahme. Für das Notfallhandbuch zur koordinierten Gefahrenabwehr entstand ein Konzept, das Befugnisse mehrerer Behörden trennt und unter Zeitdruck bedienbar bleibt. Ein bestehendes Rollenmodell lässt sich auf eine rechtebasierte Prüfung umstellen, solange die Datenhaltung das zulässt.

Hinweis: Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung dar. Für verbindliche Auskünfte zu regulatorischen Anforderungen empfehlen wir die Konsultation einer spezialisierten Rechtsberatung.

FAQs

Wer legt das Rollenmodell einer Fachanwendung fest, die Behörde oder der Dienstleister? keyboard_arrow_down keyboard_arrow_up
Die fachliche Festlegung bleibt bei der Behörde, weil nur sie ihre Geschäftsverteilung und die unvereinbaren Funktionen kennt. Der Dienstleister liefert die technische Grundlage dafür, also die einzeln prüfbaren Rechte, die frei zusammenstellbaren Profile, die Sperren für verbotene Kombinationen und die Protokollierung. TenMedia arbeitet diese Aufteilung in der Anforderungsphase mit der Fachabteilung aus und setzt sie in der Individualsoftware um, statt sie nach der Abnahme nachzurüsten. Wird die Aufteilung nicht schriftlich festgehalten, entscheidet am Ende die Software, und das fällt erst im Prüfungsfall auf, wenn eine Korrektur teuer wird.
Wie viele Rollen braucht ein Fachverfahren? keyboard_arrow_down keyboard_arrow_up
Weniger als die Beteiligten erwarten. Die Umsetzungshinweise des BSI zum Baustein ORP.4 empfehlen ausdrücklich eine begrenzte Zahl von Rechteprofilen, denen neue Beschäftigte zugeordnet werden. Entscheidend ist nicht die Anzahl, sondern dass jedes Profil einer benennbaren Aufgabe entspricht und nicht einer Stelle im Organigramm.
Wie wird eine Vertretung abgebildet, ohne Rechte dauerhaft zu erweitern? keyboard_arrow_down keyboard_arrow_up
Über eine befristete Zuweisung, die zum hinterlegten Datum von selbst verfällt. Die vertretende Person erhält das Recht zusätzlich, statt dass ihr Profil dauerhaft erweitert wird, und der Vorgang bleibt protokolliert. Ein Rollenmodell für Individualsoftware sollte diese Befristung von Beginn an vorsehen.