Zugriffsrechte nach tatsächlichen Aufgaben vergeben

Zugriff folgt einer Aufgabe und einem konkreten Gegenstand

Sinnvolle Zugriffsrechte beschreiben, welche Person welche Handlung an welchem Gegenstand unter welchen Bedingungen ausführen darf. Ein Rollenname allein beantwortet diese Frage selten vollständig. „Bearbeiten“ kann auf einen zugewiesenen offenen Vorgang begrenzt sein. „Freigeben“ kann eine andere Person und einen bestimmten Bearbeitungsstand verlangen. Die Anwendung muss diesen Zusammenhang bei der tatsächlichen Anfrage prüfen und nicht nur ein passendes Menü anzeigen.

Unser eigenes Beispiel ist eine fiktive Serviceanwendung mit mehreren voneinander getrennten Teams. Sie kennt die Aufgaben Lesen, Bearbeiten, Freigeben und Zugänge verwalten. Die Daten sind erfunden und das Modell wird nicht als bestehendes Kundensystem ausgegeben. An diesem kleinen Ablauf entwickeln wir eine Rechteübersicht, eine ausführbare serverseitige Entscheidungsfunktion und passende Gegenbeispiele. Die Funktion wird mit 68 isolierten Fällen geprüft.

Der Ausgangspunkt ist eine kurze Tätigkeitsbeschreibung. Eine Sachbearbeiterin soll offene ihr zugewiesene Vorgänge ihres Teams ändern können. Eine prüfende Person soll einen fremd erstellten Vorgang im Prüfstatus freigeben können. Die Zugangsverwaltung soll nicht allein wegen ihres technischen Namens alle fachlichen Inhalte lesen dürfen. Diese Sätze sind konkreter als eine allgemeine Forderung nach einem flexiblen Rollenmodell und lassen sich später tatsächlich testen.

Mit einer kleinen Aufgabeninventur beginnen

Schreiben Sie zunächst die wiederkehrenden Handlungen auf: ansehen, verändern, freigeben, exportieren, löschen und Zugänge vergeben. Nicht jede Anwendung braucht alle diese Aktionen. Für unser Beispiel bleiben vier eng begrenzte Aufgaben übrig. Zu jeder notieren wir den Gegenstand und die Folge eines unberechtigten Zugriffs. Dadurch wird sichtbar, wo ein bloßer Lesezugriff bereits vertrauliche Inhalte offenlegen könnte und wo eine Änderung zusätzliche Verantwortung erzeugt.

Anschließend fragen wir nach dem notwendigen Umfang. Reicht ein einzelner zugewiesener Vorgang oder braucht die Person eine ganze Teamübersicht? Ist eine Vertretung dauerhaft oder nur für einen konkreten Zeitraum vorgesehen? Eine pauschale Vollfreigabe löst diese Fragen schnell, macht spätere Entziehungen jedoch schwerer nachvollziehbar. Unser Modell beginnt deshalb mit ausdrücklichen Erlaubnissen und behandelt alle anderen Kombinationen zunächst als nicht erlaubt.

Die Aufgabeninventur wird gemeinsam mit den zuständigen Fachpersonen geprüft. Ein Entwickler kann die technische Durchsetzung bauen, sollte aber nicht aus einer vorhandenen Schaltfläche eine fachliche Berechtigung ableiten. Wenn niemand erklären kann, warum eine Rolle eine Handlung benötigt, ist das eine offene Anforderung. Eine unklare Ausnahme gehört dokumentiert und entschieden, bevor sie unbemerkt zur dauerhaften Standardberechtigung wird.

Rollen mit Beziehungen und Zuständen verbinden

Rollen bündeln ähnliche Tätigkeiten. In unserem Beispiel heißen die technischen Werte viewer, editor, reviewer und access_manager. Die sichtbaren deutschen Aufgabenbeschreibungen bleiben davon getrennt. Ein Benutzer kann mehrere bekannte Rollen besitzen. Das allein reicht jedoch nicht für jede Aktion: Teamzugehörigkeit, Zuweisung, Ersteller und Vorgangsstatus werden zusätzlich betrachtet. Die Entscheidung verbindet damit Rollen mit konkreten Eigenschaften und Beziehungen.

Ein editor darf einen offenen Vorgang nur ändern, wenn er ihm zugewiesen ist. Ein reviewer darf einen Vorgang nur im Status review freigeben und darf nicht dessen Ersteller sein. Diese Regeln sind eigene Entwurfsannahmen. Ein anderer Betrieb könnte eine strengere Trennung oder eine andere Zuständigkeit benötigen. Wichtig ist, den konkreten Grund zu verstehen und nicht aus einem Beispiel eine allgemeingültige Branchenvorschrift zu machen.

Der access_manager erhält im Modell ausschließlich die Verwaltungsaktion auf dem eigenen Teamobjekt. Ein automatischer fachlicher Lesezugriff ist nicht enthalten. Wird zusätzlich viewer vergeben, entsteht dieser Lesezugriff ausdrücklich. Damit bleibt die Rechteübersicht nachvollziehbar. Allerdings benötigt auch die Vergabe weiterer Rollen eine eigene abgesicherte Regel. Die kleine Prüffunktion entscheidet keine vollständige Rollenvergabe und behauptet keine lückenlose organisatorische Funktionstrennung.

NIST: Role Based Access Control

Anmeldung und Berechtigung auseinanderhalten

Eine erfolgreiche Anmeldung stellt fest, welcher vertrauenswürdig ermittelte Benutzerkontext vorliegt. Die Berechtigungsprüfung entscheidet anschließend, ob dieser Kontext die konkrete Handlung am konkreten Gegenstand ausführen darf. Unser Code erhält actor deshalb aus dem serverseitigen Anwendungszustand. Ein vom Browser gesendetes Objekt mit active:true und einer passenden Rollenliste wäre keine brauchbare Quelle für diese Entscheidung.

Dasselbe gilt für den Gegenstand. Der Server lädt den tatsächlichen Vorgang mit seiner Teamzuordnung, seinem Ersteller, seiner Zuweisung und seinem Status. Ein übermittelter Anzeigename oder ein im Formular versteckter Teamwert ersetzt diesen Datensatz nicht. Die Anfrage darf einen gewünschten Gegenstand benennen. Welche Eigenschaften und Zuständigkeiten er wirklich besitzt, muss aus dem vertrauenswürdigen Zustand folgen.

Unser Beispiel zeigt die reine Entscheidungsfunktion und keinen vollständigen Login, keine Datenbankabfrage und keine produktive Änderung. Diese Begrenzung ist für eine saubere Übergabe entscheidend. Ein positiver isolierter Fall beweist nur die Regelentscheidung unter den übergebenen Voraussetzungen. Die Integration muss belegen, dass genau diese Voraussetzungen tatsächlich aus den richtigen Quellen stammen und nicht vom Aufrufer selbst festgelegt werden können.

Die Teamgrenze vor jeder fachlichen Aktion prüfen

Alle fachlichen Vorgänge gehören im Beispiel zu genau einem Team. Die Entscheidung verlangt, dass die Team-ID des geladenen Gegenstands mit dem Team des aktiven Benutzers übereinstimmt. Diese Grenze gilt auch dann, wenn die Rolle grundsätzlich eine Lese- oder Freigabeaufgabe besitzt. Ein fremder Vorgang wird nicht dadurch zulässig, dass jemand seine Kennung kennt oder dieselbe Rolle in einem anderen Bereich ausübt.

Die Verwaltungsaktion verwendet ein anderes Gegenstandsformat: ein Teamobjekt statt eines Vorgangs. Auch dessen ID und Teamzuordnung müssen zusammenpassen. Dadurch wird ein fachlicher Vorgang nicht versehentlich zur Verwaltungsressource, nur weil eine Funktion einen ähnlich klingenden Namen hat. Diese ausdrückliche Trennung erleichtert die Gegenprüfung des Codes. Jede Aktion benennt, welche Art Gegenstand sie überhaupt betrifft.

Für eine reale Anwendung müssen auch Listen, Suchergebnisse, Exporte und Dateidownloads diese Grenze berücksichtigen. Eine geschützte Detailansicht allein genügt nicht, wenn dieselben Inhalte über eine andere Route abrufbar bleiben. Die Abnahme erfasst deshalb alle Wege zum betreffenden Datenbestand. Unser kleiner Baustein liefert die fachliche Entscheidung, während die vollständige Routenzuordnung und Datenauswahl gesondert geprüft werden.

OWASP API Security: Object Level Authorization

Die ausführbare Entscheidungsfunktion

Die folgende Funktion lehnt unvollständige oder unbekannte Zustände ab. Aktive Benutzer müssen eine gültige Kennung, ein Team und eine nicht leere Liste ausschließlich bekannter Rollen besitzen. Vorgänge benötigen die vereinbarten Beziehungen und einen bekannten Status. Ein nicht zugewiesener Vorgang darf assigneeId:null haben. Er bleibt für leseberechtigte Personen sichtbar, ist aber durch die Bearbeitungsregel niemandem zur Änderung zugewiesen.

Die Kennungsprüfung beschreibt nur das Format unseres fiktiven Modells. Sie ersetzt keine Suche im tatsächlichen Datenbestand und keine Anmeldung. Die Entscheidung enthält außerdem keinen versteckten allgemeinen Administratorzweig. Jede erlaubte Aktion steht ausdrücklich im Code. Eine neue Aktion ist zunächst nicht erlaubt und muss fachlich ergänzt werden. So lässt sich eine versehentliche Erweiterung beim späteren Ausbau leichter erkennen.

const knownRoles = new Set(['viewer', 'editor', 'reviewer', 'access_manager']);
const idPattern = /^[a-z][a-z0-9-]{0,63}$/;
const validId = value => typeof value === 'string' && idPattern.test(value);
const record = value => value !== null && typeof value === 'object'
  && !Array.isArray(value);

// actor and resource must come from trusted server-side state.
export function can(actor, action, resource) {
  if (!record(actor) || actor.active !== true || !validId(actor.id)
      || !validId(actor.tenantId) || !Array.isArray(actor.roles)
      || actor.roles.length === 0
      || !actor.roles.every(role => knownRoles.has(role))) return false;
  if (!record(resource) || !validId(resource.id)
      || resource.tenantId !== actor.tenantId) return false;
  const roles = new Set(actor.roles);
  if (action === 'access.manage') {
    return resource.kind === 'tenant'
      && resource.id === resource.tenantId && roles.has('access_manager');
  }
  if (resource.kind !== 'ticket' || !validId(resource.createdBy)
      || !(resource.assigneeId === null || validId(resource.assigneeId))
      || !['open', 'review', 'closed'].includes(resource.status)) return false;
  if (action === 'ticket.read') {
    return ['viewer', 'editor', 'reviewer'].some(role => roles.has(role));
  }
  if (action === 'ticket.edit') {
    return roles.has('editor') && resource.status === 'open'
      && resource.assigneeId === actor.id;
  }
  if (action === 'ticket.approve') {
    return roles.has('reviewer') && resource.status === 'review'
      && resource.createdBy !== actor.id;
  }
  return false;
}

Die positiven Fälle verständlich lesen

Für die Rechteübersicht betrachten wir einen offenen Vorgang im eigenen Team, der dem aktiven Benutzer zugewiesen und von einer anderen Person erstellt wurde. Lesen ist für viewer, editor und reviewer erlaubt. Bearbeiten ist nur für editor erlaubt. Für die Freigabespalte wechseln wir denselben Vorgang in den Prüfstatus. Dort darf reviewer freigeben, solange der Ersteller weiterhin eine andere Person ist.

Zugänge verwalten wird am eigenen Teamobjekt geprüft und ist nur für access_manager erlaubt. Diese unterschiedlichen Beispielbedingungen müssen bei einer Matrix sichtbar bleiben. Eine pauschale grüne Zelle „Freigeben“ könnte sonst fälschlich als unbeschränkte Erlaubnis für jeden Vorgang gelesen werden. Unsere Erklärung nennt daher die jeweiligen Voraussetzungen unmittelbar bei der Darstellung. Eine kompakte Übersicht darf die eigentliche Regel nicht unsichtbar machen.

Die Grafik wird aus den tatsächlich ausgeführten Ergebnissen derselben Funktion erzeugt. Sie stellt keine erfundene Sicherheitsbewertung oder Kundenberechtigung dar. Die farbliche Kennzeichnung wird mit den Wörtern Erlaubt und Nicht erlaubt ergänzt. Wer die Tabelle ohne ihre Farbe betrachtet, soll die Entscheidung weiterhin verstehen. Der sichtbare Aufgabenname erklärt die Tätigkeit und muss nicht mit dem technischen Rollenwert verwechselt werden.

Gegenbeispiele machen die Grenze belastbar

Ein offener Vorgang, der jemand anderem zugewiesen ist, darf durch unseren editor nicht geändert werden. Ein eigener zugewiesener Vorgang im Prüfstatus darf ebenfalls nicht mehr bearbeitet werden. Ein reviewer darf den selbst erstellten Vorgang auch dann nicht freigeben, wenn zusätzlich editor vergeben wurde. Mehrere Rollen heben diese konkrete Beziehungseinschränkung nicht stillschweigend auf. Genau solche Fälle verhindern ein zu grobes Verständnis von Rollenaddition.

Ein deaktivierter Benutzer wird abgewiesen. Eine unbekannte Rolle zusammen mit einer bekannten führt im bewusst strengen Beispiel ebenfalls zur Ablehnung. Das ist eine dokumentierte Modellentscheidung, die bei späteren Rollenmigrationen berücksichtigt werden muss. Wer stattdessen unbekannte Rollen ignorieren möchte, braucht dafür eine ausdrückliche andere Regel und passende Tests. Unbemerkte unterschiedliche Auslegungen zwischen zwei Diensten wären besonders schwer zu untersuchen.

Unbekannte Aktionen, fremde Teams, falsche Gegenstandsarten und unvollständige Datensätze sind weitere negative Fälle. Ein geschlossener Vorgang bleibt für berechtigte Leser sichtbar, ist aber nicht bearbeitbar oder freigebbar. Ein nicht zugewiesener Vorgang kann ebenfalls gelesen werden. Durch diese positiven Randfälle vermeiden wir, dass ein pauschales Ablehnen zwar vorsichtig aussieht, den tatsächlich benötigten Arbeitsablauf aber unnötig blockiert.

Prüfung und Änderung als zusammengehörigen Schritt integrieren

Ein Vorgang kann sich zwischen einer ersten Prüfung und einer späteren Änderung verändern. Beispielsweise könnte eine andere Person ihn inzwischen zur Prüfung abgegeben oder die Zuweisung gewechselt haben. Die produktive Umsetzung muss deshalb den aktuellen Zustand bei der entscheidenden Änderung berücksichtigen. Eine zuvor geöffnete Browseransicht ist kein verlässlicher Beleg dafür, dass die damalige Berechtigung weiterhin gilt.

Je nach Datenhaltung kann eine Transaktion, eine geeignete Sperre oder eine bedingte Änderung mit Versionsprüfung nötig sein. Die konkrete Technik hängt vom Anwendungsmodell ab. Unser reiner JavaScript-Baustein implementiert keine Datenbankatomarität. Bei der Abnahme schreiben wir ausdrücklich auf, welcher Zustand geprüft wird und was geschieht, wenn sich dieser Zustand gleichzeitig ändert. Eine gescheiterte Bedingung darf keine erfundene erfolgreiche Bearbeitung erzeugen.

Auch ein Rollenentzug braucht eine zeitliche Wirkung. Werden Rechte lange in einer Sitzung zwischengespeichert, kann der nächste Aufruf noch mit veraltetem Kontext arbeiten. Das Team legt deshalb fest, wie Änderungen an Mitgliedschaft, Aktivstatus und Rollen wirksam werden. Die gewünschte Geschwindigkeit und die technische Durchsetzung werden gemeinsam geprüft. Eine administrativ angezeigte Entziehung allein beweist noch nicht, dass jeder aktive Zugang sie bereits berücksichtigt.

Die Oberfläche aus derselben Entscheidung ableiten

Eine passende Oberfläche zeigt nur die Handlungen, die in der aktuellen Situation sinnvoll angeboten werden können. Für unseren editor kann das bedeuten, den Bearbeiten-Button nur beim eigenen offenen Vorgang zu zeigen. Das verbessert die Orientierung. Der Server muss bei der tatsächlichen Anfrage trotzdem erneut entscheiden, weil eine Schaltfläche manipuliert oder ein direkter Aufruf erzeugt werden kann.

Für eine verständliche Rückmeldung unterscheiden wir fachliche Zustandsänderung, fehlende Berechtigung und technische Störung, soweit das ohne unzulässige Informationspreisgabe möglich ist. Ein Mensch benötigt einen nächsten Schritt, beispielsweise eine aktuelle Ansicht oder einen zuständigen Ansprechpartner. Die Oberfläche soll nicht versehentlich Details eines fremden Vorgangs verraten, nur um zu erklären, warum dessen Bearbeitung nicht erlaubt ist.

Eine ausgegraute Schaltfläche kann eine nötige Information ergänzen, wenn ihre Begründung erreichbar ist. Sie darf aber nicht zum alleinigen Rechtekonzept werden. Für den Bedienentwurf verwenden wir dieselben fachlichen Aktionsnamen wie in der Aufgabeninventur. Die technische Entscheidung und die verständliche Sprache bleiben dadurch verbunden, ohne interne Rollenwerte als unverständliche Produkttexte auszugeben.

Vergabe, Vertretung und Entzug organisieren

Zur Einführung erhält jede Rolle eine zuständige fachliche Person und eine beschriebene Vergaberegel. Für eine Vertretung wird festgelegt, welche Aufgabe übernommen wird und wann diese zusätzliche Erlaubnis endet. Eine bloße Kopie aller Rechte eines Kollegen könnte dabei mehr freigeben als notwendig. Unser Modell zeigt vier getrennte Aufgaben, damit eine Vertretung gezielt begründet werden kann.

Die technische Zugangsverwaltung ist selbst eine empfindliche Aufgabe. Wer Rollen vergeben darf, könnte sich bei einer zu offenen Vergabefunktion zusätzliche Rechte verschaffen. Eine echte organisatorische Trennung braucht daher weitere Regeln über zulässige Vergaben, Freigaben und gegebenenfalls unabhängige Kontrolle. Unsere access.manage-Entscheidung ist nur der Einstieg zu dieser Verwaltungsfunktion. Sie beweist weder eine abgeschlossene Vergabelogik noch ein vollständig durchgesetztes Vieraugenprinzip.

Beim Austritt oder Aufgabenwechsel werden aktive Zugänge, laufende Sitzungen und gegebenenfalls dienstbezogene Schlüssel betrachtet. Nicht alles gehört zwangsläufig in dieselbe Anwendung. Die Zuständigkeit muss jedoch feststehen, damit ein deaktiviertes Benutzerprofil nicht durch einen vergessenen Nebenzugang wirkungslos wird. Das Rechtekonzept erhält dadurch einen Lebenszyklus statt nur einen einmaligen Stand bei der ersten Einrichtung.

Prüfnachweise und Protokolle sinnvoll aufteilen

Die 68 isolierten Fälle decken die Viermal-vier-Grundmatrix sowie fremde Teams, Aktivstatus, Zuweisung, Selbstfreigabe, kombinierte Rollen und fehlerhafte Datensätze ab. Die erwarteten Ergebnisse sind ausdrücklich festgelegt. Die Tests prüfen nicht einfach, ob die Funktion dieselbe interne Bedingung noch einmal auswertet. Sie beschreiben fachliche Situationen wie „eigener Ersteller darf nicht freigeben“ und vergleichen die tatsächliche Entscheidung.

Für eine reale Integration ergänzen wir direkte HTTP-Aufrufe, Listenabfragen, Exporte und die Änderung unter konkurrierendem Zugriff. Die reine Funktion kann diese äußeren Wege nicht beweisen. Ein eigener Test nach Rollenentzug gehört ebenfalls dazu. So bleibt sichtbar, welche Ebene ein Nachweis tatsächlich abdeckt. Eine vollständige Abnahme entsteht aus mehreren passenden Belegen und nicht aus einer einzelnen großen Anzahl grüner Prüfzeilen.

Berechtigungsrelevante Ereignisse können nachvollziehbar protokolliert werden. Dazu gehören passende technische Referenzen, Aktion, Ergebnis und ein sinnvoller Zeitpunkt. Vollständige Nutzinhalte, Zugangsschlüssel und unnötige persönliche Daten gehören nicht automatisch in jedes Protokoll. Das reale Team bestimmt den erforderlichen Umfang und den zugelassenen Zugriff darauf. Ein Protokoll ist selbst ein schützenswerter Datenbestand und kein unbegrenzter Nebenspeicher.

OWASP: Logging Cheat Sheet

Ein bestehendes System schrittweise ordnen

Bei einer bestehenden Anwendung beginnen wir mit einer Bestandsliste der Rollen und tatsächlich erreichbaren Aktionen. Unklare Sammelrollen werden nicht einfach gelöscht, solange niemand ihre Auswirkungen verstanden hat. Stattdessen ordnen wir die benötigten Aufgaben zu und prüfen die bislang genutzten Wege. Der fachliche Alltag liefert dabei wichtige Fälle: Monatsabschluss, Krankheitsvertretung, Bearbeitungswechsel und nachträgliche Korrektur können andere Voraussetzungen haben als der Standardvorgang.

Danach entsteht eine überprüfbare Zielmatrix. Für jede Änderung wird festgelegt, wer künftig eine benötigte Aufgabe übernimmt und wie eine unberechtigte Kombination abgewiesen wird. Eine schrittweise Umstellung braucht einen klaren Rückweg, ohne stillschweigend alte Vollrechte dauerhaft parallel zu behalten. Eine temporäre Ausnahme bekommt Grund, zuständige Person und Endbedingung. Sonst wird aus der geplanten Übergangsphase leicht ein zweites dauerhaftes Rechtekonzept.

Zum Abschluss prüfen wir mit den tatsächlichen Aufgabenverantwortlichen, ob notwendige Arbeit möglich und unerlaubter Zugriff verhindert ist. Beide Seiten gehören zum Ergebnis. Ein Modell, das alles erlaubt, schützt nicht. Ein Modell, das jede echte Aufgabe blockiert, funktioniert ebenfalls nicht. Gute Zugriffsrechte machen ihre Grenzen verständlich, binden sie an den aktuellen Gegenstand und bleiben bei Änderungen der Organisation überprüfbar.

Aufgaben und Bedingungen im Überblick

Checkliste für die Umsetzung

• Aufgaben, Gegenstände und benötigten Umfang beschreiben.
• Vertrauenswürdige Herkunft von Benutzer- und Gegenstandsdaten sichern.
• Teamgrenze, Zustand und Beziehungen ausdrücklich prüfen.
• Unbekannte Aktionen und unvollständige Zustände kontrolliert ablehnen.
• Alle Routen einschließlich Listen, Exporten und Downloads erfassen.
• Prüfung und Änderung gegen veralteten Zustand absichern.
• Vergabe, Vertretung, Rollenentzug und Zuständigkeiten festlegen.
• Positive, negative und konkurrierende Integrationsfälle getrennt prüfen.

Quellen und Prüfstand

Primärquellen am 09.11.2026 geprüft. Teammodell, Vorgänge und Regeln sind eigene fiktive Beispiele. Die 68 ausgeführten Prüfungen betreffen ausschließlich die gezeigte reine Entscheidungsfunktion. Sie sind keine produktive Rechteänderung oder vollständige Integrationsabnahme.

• OWASP: Authorization
• OWASP API Security: Object Level Authorization
• NIST: Role Based Access Control
• OWASP: Logging
• OWASP API Security: Function Level Authorization
• MDN: JavaScript Set