Rollenbasierte Zugriffskontrolle (Role-Based Access Control, RBAC) ist eine Methode, um in einem System zu entscheiden, wer was tun darf: Berechtigungen werden Rollen zugeordnet, und Personen werden diesen Rollen zugewiesen. Niemand erhält Berechtigungen einzeln. Ein Vertriebsmitarbeiter, ein Finance Controller und ein Support Lead erhalten jeweils den Zugriff, den ihre Aufgabe erfordert, und nicht mehr. Dieser Leitfaden erklärt, wie RBAC funktioniert, wie Sie Rollen gestalten, die überschaubar bleiben, wann attributbasierte Zugriffskontrolle (ABAC) besser geeignet ist und was sich ändert, wenn KI-Agenten beginnen, Ihre Unternehmensdaten zu lesen und zu schreiben.

Kurz gefasst

Inhaltsverzeichnis

Was rollenbasierte Zugriffskontrolle ist

RBAC ist ein Modell zur Autorisierung des Zugriffs auf Systeme, Anwendungen und Daten auf Grundlage der vordefinierten Rolle eines Nutzers. IBM beschreibt es so: Ein Administrator weist jedem Nutzer eine oder mehrere Rollen zu, wobei jede Rolle eine Reihe von Berechtigungen oder Privilegien darstellt.

Das entscheidende Merkmal ist, dass jeder Zugriff über Rollen läuft. Laut den FAQ des NIST Computer Security Resource Center ist eine Rolle im Kern eine Sammlung von Berechtigungen, und Nutzer erhalten Berechtigungen nur über die Rollen, die ihnen zugewiesen sind oder die sie über eine Rollenhierarchie erben. Das unterscheidet RBAC von gewöhnlichen Gruppen, bei denen Berechtigungen sowohl an Nutzer als auch an Gruppen gebunden sein können. NIST weist darauf hin, dass dadurch eine Lücke entsteht, die die Beziehungen zwischen Nutzern und Berechtigungen schwer kontrollierbar macht.

Ein konkretes Beispiel für ein SaaS-Unternehmen:

Rolle Typischer Zugriff im CRM Typischer Zugriff im Finanzsystem Typischer Zugriff in der Produktadministration
Account Executive Eigene Accounts und Deals, Lese- und Schreibzugriff Keiner Keiner
Sales Manager Team-Accounts, Forecast-Ansichten Nur lesender Zugriff auf den Rechnungsstatus Keiner
Finance Controller Nur lesender Zugriff auf Account-Daten Vollzugriff auf Rechnungsstellung und Reporting Keiner
Customer Success Manager Zugewiesene Accounts, Verlängerungsfelder Nur lesender Zugriff auf den Rechnungsstatus Eingeschränkte Tenant-Einstellungen
Support Engineer Nur lesender Zugriff auf Account-Kontakte Keiner Tenant-Diagnose
Administrator Konfiguration Konfiguration Vollständig

Wenn ein neuer Account Executive ins Unternehmen kommt, weisen Sie eine Rolle zu. Sie müssen nicht ein Dutzend einzelner Berechtigungsentscheidungen neu treffen.

Wie RBAC funktioniert: die drei Regeln und vier Komponenten

Das NIST-Modell beruht auf drei Regeln, wie sie in der NIST-Publikation Role Engineering: Methods and Standards dargelegt sind:

  1. Rollenzuweisung. Ein Benutzer kann eine Berechtigung nur nutzen, wenn ihm eine Rolle zugewiesen wurde.
  2. Rollenautorisierung. Die aktive Rolle des Benutzers muss für diesen Benutzer autorisiert sein.
  3. Berechtigungsautorisierung. Ein Benutzer kann eine Berechtigung nur nutzen, wenn sie für die aktive Rolle des Benutzers autorisiert ist.

Dieselbe Publikation hält fest, dass NIST im Jahr 2000 ein einheitliches RBAC-Modell vorgeschlagen hat und dass es 2004 als nationaler US-Standard INCITS 359-2004 verabschiedet wurde.

Dieser Standard besteht laut dem Dokument ANSI INCITS 359-2004 aus vier Komponenten:

Funktionstrennung ist im Finanzbereich besonders wichtig. Wer eine Zahlung an einen Lieferanten anlegt, sollte sie nicht auch freigeben. Die statische Funktionstrennung erzwingt das bei der Zuweisung, was der einfachste und am besten prüfbare Weg ist.

Wie Sie Rollen gestalten, die überschaubar bleiben

Im Design entscheidet sich, ob die meisten RBAC-Projekte gelingen oder scheitern. Ein Rollenset, das abbildet, wie das Unternehmen arbeitet, ist leicht zu erklären und zu überprüfen. Ein Rollenset, das die Kontrollkästchen jedes einzelnen Tools abbildet, wird zum Labyrinth.

Von Geschäftsfunktionen ausgehen

Laut IBMs Implementierungsleitfaden gehen die robustesten Designs von Geschäftsfunktionen und Workflows aus, nicht von Anwendungsmenüs. Fragen Sie nicht, welche Kästchen im CRM anzukreuzen sind, sondern was ein Vertriebsmitarbeiter tatsächlich tut. Drücken Sie diese Tätigkeiten dann als Rollendefinitionen aus, die sich auf mehrere Systeme abbilden lassen.

Dieser letzte Punkt ist praxisrelevant. Eine Rolle „Customer Success Manager“ sollte in Ihrem CRM, Ihrem Abrechnungstool, Ihrem Support-Desk und jedem internen Portal dasselbe bedeuten. Sie definieren sie einmal als Geschäftsrolle und ordnen sie dann jedem System zu.

Eine Geschäftsrolle, abgebildet auf vier Systeme

Einen Role-Engineering-Ansatz wählen

Die NIST-Publikation zum Role Engineering beschreibt drei Ansätze:

Auch die Identity-Dokumentation von Oracle empfiehlt den hybriden Ansatz für Role Mining. Für ein Unternehmen mit 20 bis 200 Mitarbeitenden ist der hybride Ansatz meist realistisch. Verbringen Sie einige Stunden mit der Leitung jeder Funktion, um Rollen zu entwerfen, exportieren Sie dann die aktuellen Berechtigungen aus Ihrem CRM und Ihrem Finanzsystem und prüfen Sie, wo die Realität abweicht. Die Kombination beider Ansätze vermeidet Rollen, die zu theoretisch sind, und verhindert, dass Rollen um einige wenige Ausreißer herum gebaut werden.

Eine praktische Abfolge

  1. Systeme und Daten inventarisieren. Listen Sie die Systeme auf, die Kunden-, Umsatz- und Produktdaten enthalten, und markieren Sie, welche Datensätze sensibel sind.
  2. Rollen je Funktion entwerfen. Beginnen Sie mit groben Kategorien. IBM weist darauf hin, dass Organisationen häufig damit anfangen, Administratoren, Spezialisten bzw. Expertenanwender und Endanwender zu trennen.
  3. Tatsächliche Berechtigungen exportieren. Ziehen Sie aus jedem System den aktuellen Zugriff je Person und gruppieren Sie ähnliche Muster.
  4. Abgleichen. Hat jemand weit mehr Zugriff als seine entworfene Rolle vorsieht, entscheiden Sie, ob die Rolle falsch ist oder die Person Zugriffe angesammelt hat, die sie verlieren sollte.
  5. Für jede Rolle einen Verantwortlichen benennen. Eine Person ist dafür verantwortlich, was die Rolle enthält.
  6. Anwenden, dann überprüfen. Überführen Sie die Personen in Rollen, entfernen Sie direkte Berechtigungen und planen Sie die erste Überprüfung.

RBAC Best Practices für den langfristigen Betrieb

Laut IBM hängt die langfristige Gesundheit von RBAC von der Governance ab: regelmäßige Zugriffsüberprüfungen mit Fokus auf Ausnahmen und Ausreißer, Joiner-Mover-Leaver-Prozesse, die Rollen automatisch anhand von HR-Ereignissen ändern, sowie zeitlich begrenzte, genehmigte Ausnahmen für ungewöhnliche Zugriffe.

Least Privilege durch Design umsetzen

Ein Leitfaden von Avatier zu Best Practices für Enterprise-RBAC nennt vier Mechanismen, die Least Privilege erzeugen:

Der zweite Punkt wird am häufigsten übersehen. Menschen, die das Team wechseln, sammeln Zugriffe an. Nach zwei oder drei Wechseln kann ein Customer Success Manager Rechte für die Vertriebspipeline und die Abrechnung besitzen, die niemand beabsichtigt hat.

Rollenwildwuchs verhindern

Dieselbe Quelle bezeichnet Rollenwildwuchs (Role Explosion) als das vorherrschende Fehlerbild: Für jeden Sonderfall wird eine neue, maßgeschneiderte Rolle geschaffen. Vorbeugen ist günstiger als Aufräumen. Weisen Sie jeder Rolle einen Verantwortlichen zu, kombinieren Sie lieber bestehende Rollen, statt neue zu erfinden, und rezertifizieren Sie nach einem festen Zeitplan. Ein hilfreicher Test: Hätte eine vorgeschlagene Rolle nur einen einzigen Inhaber, ist sie wahrscheinlich eine Ausnahme und keine Rolle. Behandeln Sie sie als befristete, genehmigte Ausnahme.

Den Wartungsaufwand gering halten

Okta weist darauf hin, dass RBAC keine aufwendige Wartung erfordert: Berechtigungen folgen den Rollen, sodass eine neue Funktion zu einer neuen Rolle wird, die mit geringem Administrationsaufwand auf viele Personen angewendet wird. Das gilt nur, solange der Rollensatz klein und sauber bleibt. Deshalb sind Zuständigkeit und Überprüfung wichtig.

Eine kurze Checkliste

RBAC vs. ABAC: Was brauchen Sie?

ABAC entscheidet über den Zugriff, indem Attribute des Nutzers, der Ressource, der Aktion und teilweise der Umgebung anhand einer Richtlinie ausgewertet werden. NIST SP 800-162 definiert es so und merkt an, dass ACLs und RBAC in Bezug auf die verwendeten Attribute in gewisser Hinsicht Sonderfälle von ABAC sind.

Einfach gesagt: RBAC fragt „Was ist Ihre Aufgabe?“ ABAC fragt „Was ist Ihre Aufgabe, worauf greifen Sie zu, wie viel steht auf dem Spiel und von wo?“

Oktas Vergleich besagt, dass RBAC für kleine, einfach strukturierte Arbeitsgruppen und Umgebungen mit klar definierten Funktionen geeignet ist. ABAC passt zu geografisch verteilten oder zeitlich definierten Arbeitsgruppen sowie zu Fällen, in denen sich der Zugriffsbedarf eher nach Dokument als nach Rolle richtet.

Frage RBAC ABAC
Grundlage der Entscheidung Rolle Attribute von Nutzer, Ressource, Aktion und Kontext
Einem Auditor am leichtesten zu erklären Ja Erfordert mehr Aufwand
Bildet „nur Deals unter einem bestimmten Betrag“ ab Umständlich, führt tendenziell zu mehr Rollen Natürlich
Bildet „nur Konten Ihrer Region“ ab Erfordert eine Rolle pro Region Natürlich
Einrichtungsaufwand Geringer Höher

Die meisten wachsenden SaaS-Unternehmen entscheiden sich nicht für nur eines von beiden. Oktas Identity-Team stellt fest, dass viele Organisationen einen hybriden Ansatz nutzen: RBAC für breite Zugriffsstufen und ABAC für fein abgestufte Kontrollen. Avatier betont dasselbe von der anderen Seite: RBAC ist die Basis, und kontextabhängige Entscheidungen wie Zeit, Ort, Betrag oder Gerät gehören zu ABAC, das darübergelegt wird. Die praktische Regel lautet: mit RBAC beginnen und Attributregeln nur dort ergänzen, wo sich die Zahl der Rollen sonst vervielfachen würde, etwa bei regionalen Limits oder Limits nach Dealgröße.

Interne Tools und RBAC

Bei internen Tools scheitert die Zugriffskontrolle unbemerkt. Ein Tabellenexport aus dem CRM, ein von einem einzelnen Entwickler gebautes Admin-Panel, ein per Link geteiltes Finanz-Dashboard: Jedes davon ist eine Stelle, an der Rollen umgangen werden. Drei Gewohnheiten helfen:

Wenn Sie interne Portale entwickeln oder einkaufen, fragen Sie, wie Rollen definiert werden, wer sie ändern kann und ob Änderungen protokolliert werden. Das sind die Fragen, die ein Sicherheitsprüfer oder ein Kundenfragebogen stellen wird.

RBAC, wenn KI-Agenten ins Spiel kommen

KI verändert die Frage des Zugriffs in einem bestimmten Punkt: Ein Assistent oder Agent kann in einer einzigen Anfrage auf viele Systeme zugreifen. Ist er mit einem weit gefassten Servicekonto verbunden, kann er Daten zurückgeben, die die fragende Person nie hätte sehen dürfen.

Die Lösung ist kein neues Sicherheitsmodell. Sie besteht darin, das vorhandene anzuwenden:

Es gibt auch einen Bereich, in dem KI nichts zu suchen hat: die Entscheidung darüber, wer Zugriff erhält. Das Vergeben, Ändern und Freigeben von Rollen sollte bei namentlich benannten Personen liegen, die Ihre Richtlinie anwenden. Ein Agent kann eine Prüfliste vorbereiten oder Ausreißer markieren, aber die Entscheidung verantwortet ein Mensch.

Auch die Regulierung weist in dieselbe Richtung. DSGVO, NIS2 und der EU AI Act betreffen alle, wie Daten und Systeme kontrolliert werden, und eine gut gestaltete Zugriffskontrolle ist ein gängiger Baustein, wenn Unternehmen sich damit befassen. RBAC macht ein Unternehmen nicht allein dadurch konform, und dieser Artikel ist keine Rechtsberatung. Fragen Sie Ihre Rechtsberatung, was für Sie gilt.

Mehr dazu, wie Governance und KI zusammenpassen, finden Sie in unserem AI-Governance-Framework für B2B-SaaS-Unternehmen.

Perspektive

Dasselbe Muster sehen wir in SaaS-Unternehmen mit 20 bis 200 Mitarbeitenden. Rollen wurden nie gestaltet. Der Zugriff wuchs mit jedem neuen Tool, und dann kam die KI und begann, über all das hinweg zu lesen.

Deshalb bauen wir in einer festen Reihenfolge. Zuerst das Datenfundament: Ihre CRM- und Finanzdaten als vereinbarte maßgebliche Datenquelle, mit Rollen, die in jedem System dasselbe bedeuten. Dann die KI-Schicht, die diese Daten mit dem Assistenten verbindet, den Ihr Team bereits nutzt. Danach Abteilungsagenten für Finance, Sales und Customer Success. Jede Schicht übernimmt die Zugriffsregeln der darunterliegenden.

Unsere Haltung: Ein Agent sollte nie mehr Vertrauen genießen als die Person, die ihn nutzt. Er arbeitet innerhalb der Berechtigungen dieser Person, holt eine Freigabe ein, wo eine Aktion von Bedeutung ist, und hinterlässt einen Prüfpfad. Rollendesign ist keine Nebenaufgabe eines KI-Projekts. Es ist dessen erster Baustein.

Claus Nielsen

Wo NordOps Consulting ansetzt

Wenn Ihr Team bereits KI nutzt, aber niemand verantwortet, wie sie auf Ihre Daten zugreift, ist das Zugriffsdesign ein guter erster Ansatzpunkt. NordOps Consulting arbeitet als Fractional Chief AI Officer für B2B-SaaS-Unternehmen in Europa: eine namentlich benannte Person, die entscheidet, wo sich KI auszahlt, das Datenfundament aufbaut und Agenten entwickelt, die Ihre Mitarbeitenden in einfacher Sprache nutzen, innerhalb ihrer Berechtigungen und mit Prüfpfad.

Das AI Readiness Assessment ist ein klar definierter Einstieg, ab €4,500. Für die laufende Verantwortung beginnt das Fractional-CAIO-Retainer ab €1,500 pro Monat. Sie können auch mit einem kostenlosen 30-minütigen Erstgespräch über unsere Website beginnen. Wie die Arbeit gestaffelt ist, lesen Sie unter So funktioniert es, oder werfen Sie einen Blick auf das Admin Portal, in dem Benutzerrollen und Zugriffe zusammen mit den Agenten verwaltet werden.

FAQ

Was ist der Unterschied zwischen einer Rolle und einer Berechtigung?

Eine Berechtigung ist eine einzelne erlaubte Aktion auf eine Ressource, etwa das Lesen einer Rechnung oder das Bearbeiten eines Deals. Eine Rolle ist eine benannte Sammlung von Berechtigungen, die zu einer Funktion im Unternehmen passt. Benutzern werden Rollen zugewiesen, und die Rollen tragen die Berechtigungen.

Reicht RBAC aus, oder brauche ich ABAC?

Für die meisten Teams ist RBAC der richtige Ausgangspunkt, weil es einfach zu erklären und zu prüfen ist. Ergänzen Sie ABAC-Regeln nur dann, wenn der Kontext eine Rolle spielt, etwa bei Zugriffsbeschränkungen nach Region, Dealgröße oder Zeit. Viele Organisationen setzen beides ein: RBAC für die groben Stufen und ABAC für feine Details.

Wie viele Rollen sollte ein Unternehmen haben?

Es gibt keine Standardzahl. Binden Sie Rollen an reale Funktionen, geben Sie jeder einen Verantwortlichen und behandeln Sie einmalige Bedarfe als befristete Ausnahmen. Wenn eine Rolle nur einen einzigen Inhaber hätte, ist das ein Zeichen dafür, dass es sich um eine Ausnahme und nicht um eine Rolle handelt.

Wie oft sollten Rollen und Zugriffe überprüft werden?

Legen Sie einen regelmäßigen Turnus fest und prüfen Sie zusätzlich, sobald jemand die Stelle wechselt oder das Unternehmen verlässt. Die Empfehlungen von IBM sehen regelmäßige Zugriffsprüfungen vor, die sich auf Ausnahmen und Ausreißer konzentrieren, sowie automatisierte Änderungen, die durch HR-Ereignisse ausgelöst werden. Wählen Sie einen Rhythmus, den Ihr Team einhalten kann, denn eine versäumte Prüfung ist schlimmer als eine schlankere.

Wie sollten KI-Agenten in einem RBAC-Modell behandelt werden?

Behandeln Sie sie als im Auftrag einer Person handelnd, mit der Rolle dieser Person und nicht mehr. Trennen Sie Lese- und Schreibberechtigungen, verlangen Sie für sensible Aktionen eine Freigabe und protokollieren Sie jede Aktion. Entscheidungen darüber, wer Zugriff erhält, sollten bei Menschen bleiben.

Quellen