RBAC vs ABAC für interne Tools: Zugriffsrechte wählen, die mitwachsen

Warum Berechtigungen in internen Tools schnell unübersichtlich werden

Interne Tools stehen sehr nahe an den sensibelsten Teilen eines Unternehmens: Kundendaten, Rückerstattungen, Rechnungen, Gehaltsnotizen, Deal-Werte und private interne Kommentare. Nicht jede:r sollte alles sehen können, und noch weniger Personen sollten alles bearbeiten dürfen.

Berechtigungen beginnen meist einfach: „Support darf Tickets ansehen“, „Finanzen können Rückerstattungen genehmigen“, „Manager sehen Team-Performance“. Dann wächst die Organisation, Prozesse ändern sich, und das Tool wird zu einem Flickenteppich von Ausnahmen.

Dieses „explodiert später“-Muster ist häufig:

• Rollenwucher: Du fügst Support hinzu, dann Support - Senior, dann Support - EU, dann Support - EU - Nachtschicht, bis niemand mehr weiß, was jede Rolle genau beinhaltet.
• Ausnahmeansammlung: Ein paar Leute brauchen „nur eine zusätzliche Berechtigung“, also häufen sich einmalige Schalter.
• Unbeabsichtigte Offenlegung: Jemand kann Gehaltsnotizen, Kunden-PII oder Umsatzberichte sehen, weil ein Screen wiederverwendet wurde, ohne den Zugriff zu prüfen.
• Gebrochene Workflows: Ein:e Benutzer:in kann einen Datensatz sehen, aber den nächsten Schritt nicht ausführen (oder schlimmer: ohne den Kontext den Schritt ausführen).
• Schmerzhafte Audits: Es ist schwer, zu beantworten: „Wer kann Rückerstattungen über $1.000 genehmigen?“ ohne manuelles Graben.

Der Sinn, früh RBAC oder ABAC zu wählen, ist nicht nur, Bildschirme abzusichern. Es geht darum, Regeln verständlich zu halten, wenn neue Teams, Regionen und Policies auftauchen.

Ein Berechtigungsmodell, das Bestand hat, hat vier Eigenschaften: Es ist leicht zu erklären, einfach zu prüfen, schwer zu missbrauchen und schnell zu ändern.

RBAC einfach erklärt (Rollen und was sie freischalten)

RBAC (rollenbasierte Zugriffskontrolle) ist der „Jobtitel“-Ansatz. Ein:e Nutzer:in erhält eine oder mehrere Rollen (z. B. Support-Mitarbeiter:in, Admin). Jede Rolle kommt mit einem festen Satz an Dingen, die diese Rolle sehen oder tun darf. Teilen zwei Personen dieselbe Rolle, erhalten sie denselben Zugriff.

RBAC funktioniert gut, wenn Teams größtenteils gleichartig arbeiten und die Hauptfragen featurebasiert sind: „Darf sie diesen Screen nutzen?“ oder „Darf er diese Aktion ausführen?“

Beispielrollen für ein Support-Console:

• Support-Mitarbeiter:in: Tickets ansehen, Kunden beantworten, interne Notizen hinzufügen
• Support-Leiter:in: alles, was ein:e Mitarbeiter:in kann, plus Tickets neu zuweisen und Team-Metriken sehen
• Admin: Nutzer verwalten, Systemeinstellungen ändern, Berechtigungsregeln bearbeiten

Die Kernidee ist, dass Rollen Verantwortung abbilden, nicht einzelne Personen. Wenn Verantwortung stabil ist, bleiben Rollen stabil und das Modell bleibt leicht zu erklären.

RBAC passt gut, wenn:

• Das Organigramm klar ist (Teams, Teamleitungen, Admins)
• Die meisten Zugriffsentscheidungen „Kann sie dieses Feature nutzen?“ sind
• Das Onboarding vorhersehbar sein muss (Rolle X zuweisen und fertig)
• Audits wichtig sind (einfach aufzulisten, was eine Rolle darf)

Wo RBAC anfängt zu schmerzen, ist, wenn die Realität unordentlich wird. Interne Tools sammeln Ausnahmen: ein Support-Mitarbeiter, der rückerstatten darf, ein Finance-User, der nur eine Region sehen sollte, ein Auftragnehmer, der Tickets sehen, aber keine Kunden-PII einsehen darf. Wenn du jede Ausnahme durch eine neue Rolle löst, entsteht Rollenexplosion.

Ein praktisches Signal, dass RBAC allein versagt: Du fängst an, jede Woche „Spezialrollen“ hinzuzufügen.

ABAC einfach erklärt (Regeln basierend auf Attributen)

ABAC (attributbasierte Zugriffskontrolle) entscheidet über Regeln, nicht nur Jobtitel. Statt „Was kann die Finance-Rolle?“ fragt ABAC: „Angesichts dessen, wer diese Person ist, was dieser Datensatz ist und was gerade passiert, sollten wir das erlauben?“

Attribute sind Fakten, die du ohnehin trackst. Eine Regel könnte lauten:

• „Support-Mitarbeiter:innen dürfen Tickets in ihrer Region ansehen.“
• „Manager:innen dürfen Ausgaben unter 5.000 $ während der Geschäftszeiten genehmigen.“

Die meisten ABAC-Systeme nutzen ein paar Attributkategorien:

• Nutzerattribute: Abteilung, Region, Manager-Status
• Datenattribute: Datensatz-Besitzer, Ticket-Priorität, Rechnungsstatus
• Kontextattribute: Tageszeit, Gerätetyp, Netzwerkstandort
• Aktionsattribute: ansehen vs bearbeiten vs exportieren

Konkretes Beispiel: Ein Support-Mitarbeiter darf ein Ticket nur bearbeiten, wenn (a) die Ticket-Priorität nicht kritisch ist, (b) das Ticket ihm zugewiesen ist und (c) die Kunden-Region mit seiner Region übereinstimmt. So vermeidest du separate Rollen wie Support - EU - Nicht-kritisch und Support - US - Nicht-kritisch.

Der Kompromiss ist, dass ABAC schwer zu durchdenken werden kann, wenn sich Ausnahmen weiter anhäufen. Nach ein paar Monaten können Leute grundlegende Fragen wie „Wer darf Rechnungen exportieren?“ nicht mehr beantworten, ohne eine lange Bedingungskette zu lesen.

Eine gute ABAC-Gewohnheit ist, Regeln wenig, konsistent und in klarer Sprache zu halten.

Datensatz-Level-Zugriff: Hier passieren die meisten Fehler

Viele Teams behandeln Berechtigungen als „Darf den Screen öffnen?“. Das ist nur die erste Schicht. Datensatz-Level-Zugriff beantwortet eine andere Frage: Selbst wenn du den Screen öffnen darfst, welche Zeilen darfst du sehen oder ändern?

Ein Support-Mitarbeiter und ein Finance-Analyst könnten beide eine Kunden-Seite aufrufen. Wenn du beim Screen-Level stoppst, läufst du Gefahr, allen alles zu zeigen. Datensatzregeln schränken ein, welche Daten innerhalb dieser Seite geladen werden.

Gängige Datensatzregeln sind:

• Nur deine Kunden (assigned_owner_id = current_user.id)
• Nur deine Region (customer.region IN current_user.allowed_regions)
• Nur deine Kostenstelle (invoice.cost_center_id IN current_user.cost_centers)
• Nur die Tickets deines Teams (ticket.team_id = current_user.team_id)
• Nur Datensätze, die du erstellt hast (created_by = current_user.id)

Datensatz-Level-Zugriff muss dort durchgesetzt werden, wo Daten abgefragt und geändert werden, nicht nur in der UI. In der Praxis heißt das: Abfrage-Layer, API-Endpunkte und Business-Logik.

Ein typischer Fehlermodus ist „gesperrte Seite, offene API“. Ein Button ist für Nicht-Admins versteckt, aber der Endpoint liefert trotzdem alle Datensätze. Jede:r mit Zugriff auf die App kann gelegentlich diesen Aufruf auslösen, indem sie/er eine Anfrage wiederverwendet oder einen Filter ändert.

Prüfe dein Modell mit ein paar Fragen:

• Wenn ein:e Nutzer:in den Endpoint direkt aufruft, bekommt sie/er trotzdem nur erlaubte Datensätze?
• Wenden Listen-, Detail-, Export- und Zählendpunkte dieselben Regeln an?
• Werden Create-, Update- und Delete-Operationen separat geprüft (nicht nur Read)?
• Umgehen Admins Regeln absichtlich oder aus Versehen?

Screen-Berechtigungen entscheiden, wer einen Raum betreten darf. Datensatz-Level-Zugriff entscheidet, welche Schubladen sie öffnen können, wenn sie drinnen sind.

Reale Beispiele: Support, Finanzen und Manager

Das Ziel ist nicht „perfekte Sicherheit“. Es sind Berechtigungen, die Menschen heute verstehen und später ändern können, ohne Workflows zu zerstören.

Support-Team

Support braucht in der Regel Datensatzregeln, weil „alle Tickets“ selten zutrifft.

Ein einfaches Modell: Agent:innen können Tickets öffnen und aktualisieren, die ihnen zugewiesen sind, plus alles in ihrer Queue. Team-Leads können Tickets neu zuweisen und bei Eskalationen eingreifen. Manager brauchen oft Dashboards ohne die Fähigkeit, jedes Ticket zu bearbeiten.

Massenaktionen und Exporte sind die typische Kniffligkeit. Viele Teams erlauben Bulk-Close, beschränken Bulk-Reassign und limitieren Exporte auf Leads und Manager mit Protokollierung.

Finanzteam

Zugriffe in Finanzen drehen sich meist um Genehmigungsschritte und eine saubere Prüfspur.

Eine gängige Konstellation: Ein Sachbearbeiter (AP clerk) kann Rechnungen erstellen und als Entwurf speichern, aber nicht genehmigen oder zahlen. Ein Controller kann genehmigen und Zahlungen freigeben. Auditoren sollten nur Lesezugriff haben, inklusive Anhängen, ohne Lieferanteninformationen ändern zu dürfen.

Eine realistische Regel lautet: „AP-Sachbearbeiter können Entwürfe bearbeiten, die sie erstellt haben; nach Einreichung darf nur der Controller Änderungen vornehmen.“ Das ist Datensatz-Level-Zugriff (Status + Besitzer) und passt oft besser zu ABAC als neue Rollen zu erstellen.

Manager

Die meisten Manager benötigen breite Sichtbarkeit, aber eingeschränkte Bearbeitungsrechte.

Ein praktisches Muster: Manager können die meisten operativen Daten sehen, dürfen aber nur Datensätze bearbeiten, die ihrem Team gehören oder mit ihren direkten Berichten verknüpft sind (Urlaubsanträge, Ziele, Leistungsnotizen). Attribute wie team_id, manager_id und employment_status sind oft klarer, als für jede Abteilung eine eigene Rolle zu schaffen.

Über diese Gruppen hinweg brauchst du typischerweise:

• Support: Sichtbarkeit nach Zuweisung/Queue, vorsichtige Exporte, kontrollierte Neu-Zuweisung
• Finanzen: statusbasierte Regeln (Entwurf vs. eingereicht vs. genehmigt), strenge Genehmigungen, prüfsichere Lesezugriffe
• Manager: breite Ansicht, schmale Bearbeitung (team-eigene oder direkte Bericht-Datensätze)

Entscheidungs-Matrix: Rollen vs Attribute vs Datensatzregeln

Statt zu streiten „was besser ist“, frage, welche Teile deines Zugriffsproblems zu welchem Modell passen. Die meisten Teams landen bei einem Hybrid: Rollen für grobe Zugänge, Attribute für Ausnahmen und Datensatzfilter für „nur mein Kram“.

Behandle Berechtigungslogik wie eine monatliche Rechnung. Jede zusätzliche Rolle, Regel und Ausnahme kostet Zeit zum Testen, Erklären und Debuggen. Gib so wenig aus wie nötig, um reale Szenarien heute abzudecken.

Ein praktischer Default:

• Starte mit RBAC für grobe Bahnen (Support, Finanzen, Manager).
• Füge ABAC für wiederkehrende Bedingungen hinzu (Region, Seniorität, Kundentier).
• Füge Datensatzregeln hinzu, wenn Nutzer „ihre“ Items sehen sollen, nicht die gesamte Tabelle.

Schritt für Schritt: Berechtigungen entwerfen, bevor du Bildschirme baust

Wenn du Berechtigungen erst nach der UI entscheidest, endest du meist mit zu vielen Rollen oder einer Menge Spezialfälle. Ein einfacher Plan verhindert ständige Nachbesserungen.

1) Fang mit Aktionen an, nicht mit Bildschirmen

Schreibe auf, was Menschen in jedem Workflow tatsächlich tun:

• View (lesen)
• Create (erstellen)
• Edit (bearbeiten)
• Approve (genehmigen)
• Export (exportieren)
• Delete (löschen)

Im Rückerstattungs-Flow ist Approve nicht dasselbe wie Edit. Diese Unterscheidung entscheidet oft, ob du eine strikte Regel oder nur eine Rolle brauchst.

2) Definiere Rollen, die Jobtitel abbilden

Wähle Rollen, die Leute ohne Erklärung erkennen: Support-Mitarbeiter:in, Support-Leiter:in, Finance-Analyst:in, Finance-Manager:in, Auditor, Admin. Vermeide Rollen wie „Support-Mitarbeiter:in - Kann VIP-Notizen bearbeiten.“ Solche Rollen explodieren schnell.

3) Liste Attribute auf, die echte Ausnahmen erzeugen

Füge ABAC nur dort hinzu, wo es sich lohnt. Typische Attribute sind Region, Team, Kundentier, Besitz und Betrag.

Wenn eine Ausnahme seltener als einmal im Monat vorkommt, erwäge einen manuellen Genehmigungsschritt statt einer dauerhaften Berechtigungsregel.

4) Schreibe Datensatzregeln als Ein-Satz-Policies

Datensatz-Level-Zugriff ist der Hauptbruchpunkt interner Tools. Schreibe Regeln, die du einem nicht-technischen Manager zeigen könntest:

„Support-Mitarbeiter:innen können Tickets in ihrer Region sehen.“

„Finance-Analyst:innen können Rechnungen bearbeiten, die sie erstellt haben, bis sie genehmigt sind.“

„Manager:innen können Rückerstattungen über $500 nur für ihr Team genehmigen.“

Wenn du eine Regel nicht in einem Satz ausdrücken kannst, ist der Prozess wahrscheinlich unklar.

5) Teste mit fünf echten Personen, bevor du baust

Gehe reale Szenarien durch:

• Ein Support-Mitarbeiter bearbeitet einen VIP-Kunden
• Ein Finance-Analyst korrigiert eine Rechnung
• Ein Manager genehmigt eine hohe Rückerstattung
• Ein Admin führt Wartung durch
• Ein Auditor, der Historie sehen, aber nichts ändern darf

Behebe Verwirrungen hier, bevor sie zu einem Berechtigungs-Labyrinth werden.

Häufige Fallen (und wie man sie vermeidet)

Die meisten Berechtigungsfehler entstehen nicht durch die Wahl zwischen RBAC oder ABAC. Sie entstehen, wenn kleine Ausnahmen sich anhäufen, bis niemand mehr erklären kann, wer was und warum tun darf.

Rollenexplosion beginnt oft mit „Der Support-Leiter braucht einen zusätzlichen Button“, dann entstehen 25 Rollen, die sich in einer Berechtigung unterscheiden. Halte Rollen breit (aufgabenorientiert) und nutze eine kleine Anzahl regelbasierter Ausnahmen für wiederkehrende Randfälle.

Unlesbare Attributlogik ist die ABAC-Version desselben Problems. Wenn du Bedingungen wie „department == X AND region != Y“ überall verstreut hast, werden Audits zum Ratespiel. Nutze benannte Policies (selbst wenn es nur konsistente Labels in einem geteilten Dokument sind), sodass du sagen kannst „RefundApproval-Policy“ statt eine Formel zu entschlüsseln.

Exporte, Reports und Massenaktionen sind die Bereiche, in denen Leaks passieren. Teams sichern eine Ansicht, vergessen dann aber, dass Export CSV oder Massenupdates dieselben Prüfungen umgehen. Behandle jeden Nicht-Screen-Pfad als erstklassige Aktion mit eigener Berechtigungsprüfung.

Fallen, auf die du achten solltest:

• Für jede Ausnahme eine neue Rolle erstellen
• Attributregeln, die schwer lesbar oder unbenannt sind
• Exporte, geplante Reports und Massenaktionen, die Checks überspringen
• Verschiedene Tools, die dieselbe Zugriffsfrage unterschiedlich beantworten
• Datensatzregeln, die an einer Stelle angewendet, an einer anderen aber fehlen

Die sicherste Lösung ist eine Single-Source-of-Truth für Rollen, Attribute und Datensatzregeln, die konsequent in der Backend-Logik durchgesetzt wird.

Schnelle Checkliste, bevor du live gehst

Wenn dein Modell schwer zu erklären ist, wird es schwerer zu debuggen, wenn jemand sagt: „Ich sollte diesen Kunden sehen können“ oder „Warum kann sie diese Liste exportieren?"

Fünf Prüfungen, die die meisten Überraschungen aufdecken:

• Kann ein:e echte:r Nutzer:in seinen/ihren Zugriff in einem Satz beschreiben (z. B.: „Ich bin Support, Region = EU, ich kann Tickets für meine Region sehen, aber nicht exportieren“)? Wenn nicht, sind die Regeln wahrscheinlich zu verstreut.
• Hast du eine explizite Antwort auf „Wer darf exportieren?“ und „Wer darf genehmigen?“ Behandle Export und Genehmigung als hochriskante Aktionen.
• Werden Datensatzregeln überall durchgesetzt, wo Daten abgefragt werden (API-Endpunkte, Reports, Background-Jobs), nicht nur durch das Verstecken von Buttons?
• Ist die Standardeinstellung für sensible Aktionen sicher (deny by default)? Neue Rollen, Attribute und Screens sollten nicht versehentlich mächtige Berechtigungen erben.
• Kannst du in unter einer Minute mit einer einzigen Quelle der Wahrheit beantworten: „Wer kann diesen konkreten Datensatz sehen und warum?“ (Rolle, Attribute und Besitz/Status des Datensatzes)

Beispiel: Finanzen können vielleicht alle Rechnungen sehen, aber nur Approver dürfen genehmigen, und nur Manager dürfen eine vollständige Lieferantenliste exportieren. Support kann Tickets sehen, aber nur das Team des Ticket-Eigentümers sieht interne Notizen.

Berechtigungsänderungen vornehmen, ohne alles kaputt zu machen

Berechtigungen ändern sich aus banalen Gründen: ein neuer Manager, Finanzen teilen sich in AP und AR, oder das Unternehmen übernimmt ein anderes Team. Plane für Änderungen, sodass Updates klein, reversibel und leicht prüfbar sind.

Vermeide es, Zugriff an eine große „Superrolle“ zu binden. Füge neuen Zugriff entweder als neue Rolle, neues Attribut oder enge Datensatzregel hinzu und teste ihn gegen reale Aufgaben.

Zugriff hinzufügen, ohne alles neu zu entwerfen

Wenn eine neue Abteilung entsteht (oder durch eine Übernahme Teams hinzukommen), halte die Kernrollen stabil und füge Schichten darum herum:

• Behalte Basisrollen gering (Support, Finanzen, Manager) und füge kleine Add-ons hinzu (Refunds, Export, Approvals).
• Bevorzuge Attribute für Organisationsänderungen (Team, Region, Kostenstelle), damit neue Gruppen nicht neue Rollen brauchen.
• Nutze Datensatzregeln für Besitz und Zuweisung (ticket.assignee_id, invoice.cost_center).
• Füge einen Genehmigungsschritt für sensible Aktionen hinzu (Auszahlungen, Abschreibungen).
• Behandle Export fast überall als eigene Berechtigung.

Temporärer Zugriff sollte keine permanente Rollenänderung erfordern. Für Urlaubsvertretung oder Incident-Response nutze zeitlich begrenzte Grants: „Finance-Approver für 48 Stunden“ mit Enddatum und erforderlichem Grund.

Audit-Rhythmus und logs für Untersuchungen

Nutze eine einfache Review-Routine: monatlich für Hochrisiko-Berechtigungen (Geld, Exporte), vierteljährlich für den Rest und nach jeder Reorg oder Übernahme.

Logge genug, um zu beantworten, wer was, an welchem Datensatz und warum erlaubt hat:

• Wer hat angesehen, bearbeitet, genehmigt oder exportiert
• Wann es passiert ist (und von wo, falls erfasst)
• Welcher Datensatz betroffen war (IDs, Typ, Vorher/Nachher bei Änderungen)
• Warum es erlaubt war (Rolle, Attribute, Datensatzregel, temporäre Gewährung)
• Wer Zugriff gewährt hat (und wann er verfällt)

Nächste Schritte: Ein Modell implementieren, das du pflegen kannst

Starte mit einem kleinen, langweiligen Berechtigungsmodell. Das überlebt sechs Monate Veränderungen.

Ein guter Default ist simples RBAC: eine Handvoll Rollen, die echten Jobfunktionen entsprechen (Support-Mitarbeiter:in, Support-Leiter:in, Finanzen, Manager, Admin). Verwende diese Rollen, um große Türen zu kontrollieren: welche Screens existieren, welche Aktionen verfügbar sind und welche Workflows gestartet werden können.

Füge ABAC nur dort hinzu, wo du immer wieder dieselben Ausnahmen siehst. Wenn der einzige Grund für ABAC „es könnte später nützlich sein“ ist, warte. ABAC glänzt, wenn Bedingungen wichtig sind (Betragsgrenzen, Regionsbeschränkungen, Besitz, Status), aber es braucht sorgfältige Tests und klare Verantwortlichkeiten.

Schreibe Regeln zuerst als einfache Sätze. Wenn eine Regel schwer in einem Satz zu sagen ist, wird sie schwer zu pflegen sein.

Wenn du schnell pilotieren willst, kann eine No-Code-Plattform wie AppMaster (appmaster.io) helfen, Rollen, Datenfelder wie owner/team/status und backend-gesicherte Workflows früh zu modellieren, bevor UI-Entscheidungen riskante Annahmen verankern.