RBAC und Rechtemanagement: Wer darf in einem Treuhand-System was sehen?

Was ist RBAC und wo grenzt sich ABAC ab?

Role-Based Access Control, kurz RBAC, ist das seit den 1990er Jahren etablierte Modell der Zugriffs-Verwaltung. Statt Berechtigungen an einzelne Personen zu vergeben, definiert man Rollen (Lehrling, Sachbearbeiter, Mandats-Leiter, Geschäftsführer), hängt an jede Rolle ein Bündel von Rechten und ordnet Mitarbeitende einer oder mehreren Rollen zu. Beim Mitarbeiter-Wechsel wechselt die Rolle, nicht die einzelnen Rechte.

Attribute-Based Access Control (ABAC) geht einen Schritt weiter und entscheidet anhand von Attributen – Tageszeit, Standort, Mandanten-Kategorie, Vertraulichkeits-Stufe des Dokuments, Gerät, Netzwerk-Zone. Beispiel: „Sachbearbeiter Müller darf Dokumente der Kategorie B-Mandat lesen, aber nur während Büroaeffnungs-Zeiten und nur aus dem CH-IP-Bereich." RBAC wäre für diesen Fall zu starr, ABAC modelliert die Bedingung sauber.

In der Praxis kombinieren produktive Systeme beides. RBAC liefert die grobe Struktur (Lehrling, Sachbearbeiter, Mandats-Leiter), ABAC die feinen Bedingungen (nur eigene Mandanten, nur während Geschäftszeiten, nur mit Zwei-Faktor-Authentisierung). Das Modell heisst dann RBAC-ABAC-Hybrid und ist Mai 2026 in praktisch jedem Enterprise-IAM-System (Keycloak, Okta, Entra) als Default-Konfiguration möglich.

Drei Prinzipien sind nicht verhandelbar. Least Privilege: Jeder Mitarbeitende bekommt nur die minimalen Rechte für seine tägliche Arbeit, nicht mehr. Separation of Duties: Wer Belege erfasst, freigibt sie nicht selbst – vier-Augen-Prinzip bei kritischen Schritten. Need-to-Know: Wer keinen Auftrag hat, einen Mandanten zu bearbeiten, sieht dessen Daten nicht – auch nicht „aus Neugier".

Warum es wichtig ist

Drei rechtliche Anker zwingen zu sauberem Rechtemanagement. Erstens das Berufsgeheimnis nach Art. 321 StGB und BGFA: Wer in einer Anwaltskanzlei oder Treuhand-Praxis arbeitet, darf Mandanten-Daten nicht an Unbeteiligte weitergeben. „Unbeteiligt" umfasst auch interne Mitarbeitende, die keinen Mandats-Auftrag haben. Ohne technisch durchgesetzte Mandanten-Trennung wäre ein einziger Lehrling, der versehentlich eine Datei öffnet, ein Straftätter – und die Kanzlei haftet.

Zweitens das revDSG / revFADP: Art. 8 verlangt angemessene technische und organisatorische Massnahmen zum Schutz von Personendaten. Ein offenes Dateisystem ohne Rollen-Trennung ist nicht angemessen. Bei Datenpannen muss laut Art. 24 revDSG eine Meldung an den EDÖB erfolgen; ohne sauberes RBAC lässt sich nicht sagen, welche Daten an wen geleakt sind.

Drittens die GeBüV und Art. 957a OR: Jede Berechtigungs-Änderung an buchhalterisch relevanten Systemen muss geloggt sein. Wer hat am 12. März die Berechtigung „Buchung freigeben" auf den Lehrling ausgedehnt? Ohne Audit-Trail kann ein Prüfer das nicht nachvollziehen und die Geschäftsführung steht ohne Beleg da.

Dazu kommt der praktische Schutz vor Insider-Bedrohungen. Verizon DBIR 2026 nennt 18 Prozent aller Daten-Vorfälle als Insider-Verursacht – durch Fahrlässigkeit oder böse Absicht. Ein Mitarbeitender, der nur seine eigenen Mandanten sieht, kann selbst bei bösem Willen nur einen begrenzten Schaden anrichten.

Wie ein RBAC-Setup im Treuhand-KMU aussieht

Wir gehen einen konkreten Aufbau Schritt für Schritt durch. Eine 8-Personen-Treuhand mit 180 Mandanten.

Rollen-Modell: Lehrling (lesen interne Wegleitungen, lesen zugewiesene Mandanten ohne Schreib-Recht), Sachbearbeiter (lesen und schreiben zugewiesene Mandanten, kein Freigabe-Recht), Mandats-Leiter (alles am eigenen Mandat inklusive Freigabe), Geschäftsführer (Voll-Zugriff auf alle Mandate plus User-Verwaltung), externer Revisor (zeitlich befristeter Lesezugriff auf einen Mandanten).

Mandanten-Trennung: Jedem Mandanten wird eine ACL zugeordnet, die nur die Mitarbeitenden enthält, die an diesem Mandat arbeiten. Der Sachbearbeiter Müller sieht in seiner Mandanten-Liste nur seine 25 zugewiesenen Mandate – die anderen 155 existieren für ihn nicht. Das ist nicht „nur ausgegraut", sondern technisch durchgesetzt: Eine direkte URL-Manipulation, die zu einem fremden Mandanten führen würde, gibt einen 403-Fehler.

Identity-Provider: Mai 2026 sind im OSS-Bereich Authelia (Go, leichtgewichtig, gut für kleine Setups) und Authentik (Python, breitere Funktionalität, GUI-Verwaltung) die beiden Empfehlungen. Beide sprechen OIDC und SAML 2.0 und integrieren sich in alle gängigen Web-Anwendungen. Keycloak von Red Hat ist die Enterprise-OSS-Variante mit voller Federation, IdP-Brokerage und SCIM-Provisioning. Im Cloud-Bereich sind Okta und Microsoft Entra (früher Azure AD) Standard, beide mit SCIM und Conditional Access.

SSO-Standards: SAML 2.0 ist der ältere, robuste Standard für Browser-basierte Single-Sign-On. OIDC (OpenID Connect) ist die moderne, JSON-basierte Variante und Mai 2026 die bevorzugte Wahl für neue Integrationen. SCIM (System for Cross-domain Identity Management) automatisiert das User-Provisioning: Wenn HR im zentralen System einen Mitarbeitenden anlegt oder austragen lässt, propagiert SCIM diese Änderung in alle angeschlossenen Anwendungen.

Multi-Faktor-Authentisierung: Mai 2026 ist Passwort plus Hardware-Token (YubiKey, Titan Key) oder TOTP via Authenticator-App der absolute Mindeststandard für geschäftsrelevante Systeme. SMS als zweiter Faktor ist abgekündigt, weil SIM-Swap-Angriffe in der Schweiz dokumentiert sind. Phishing-resistente WebAuthn-Schlüssel sind die robusteste Variante.

Audit-Trail: Jede Berechtigungs-Änderung wird mit User, Zeit, alter und neuer Wert, ausführendem Account in eine append-only Tabelle geschrieben. Nach Art. 957a OR muss dieses Log 10 Jahre aufbewahrt werden. Der Audit-Trail muss tamper-evident sein – entweder über Hashketten (jeder Eintrag enthält den Hash des Vorgängers) oder über WORM-Storage (S3 Object Lock, MinIO Object Lock).

Joiner-Mover-Leaver-Prozess: Jeder Mitarbeitender-Wechsel folgt einem dokumentierten Ablauf. Neuer Mitarbeitender (Joiner): Rolle wählen, Zugriff einrichten, Schulung. Wechsel in andere Funktion (Mover): alte Rechte entziehen, neue zuweisen, Übergangs-Zeit von max. 30 Tagen. Austritt (Leaver): Alle Zugriffe innert 1 Stunde nach Austritt deaktivieren – am Tag des Austritts vor 18:00 Uhr ist Pflicht. Quartalsweise Access-Review: Jeder Mandats-Leiter prüft die Mitarbeitenden auf seinen Mandaten.

RBAC-Implementierung in 5 Schritten

1. 01Rollen-Inventar: Listen Sie alle Mitarbeitenden-Klassen mit ihren typischen Aufgaben. Schneiden Sie nicht zu fein – 4 bis 6 Rollen reichen für ein KMU.
2. 02Permission-Katalog: Pro Rolle die maximal nötigen Rechte definieren. Least Privilege als Leitprinzip – im Zweifel weniger.
3. 03Identity-Provider wählen: Authelia oder Authentik für kleine OSS-Setups, Keycloak für mittelgrosse mit Federation, Okta oder Entra für Cloud-Standard. SSO über SAML 2.0 oder OIDC.
4. 04Mandanten-ACL einrichten: Jeder Mandant bekommt eine Liste der zugriffsberechtigten Mitarbeitenden. Technisch durchgesetzt mit 403 bei URL-Manipulation.
5. 05Joiner-Mover-Leaver-Prozess plus Audit-Trail: HR-System löst SCIM-Sync aus, jede Änderung wird tamper-evident geloggt, quartalsweise Access-Review durch Mandats-Leiter.

Wann RBAC zwingend ist

RBAC mit Mandanten-Trennung ist zwingend in allen Betrieben mit Berufsgeheimnis: Anwaltskanzleien, Treuhand, Steuerberatung, Arztpraxen, Psychotherapie-Praxen, Notariate, Vermögensverwalter. Hier verlangt das Gesetz selbst die Trennung, nicht nur die gute Praxis.

Auch für alle Betriebe, die besonders schützenswerte Personendaten nach Art. 5 revDSG bearbeiten – Gesundheit, religiöse, weltanschauliche, politische, gewerkschaftliche Ansichten, Massnahmen der sozialen Hilfe, Strafverfolgungs-Daten –, ist RBAC mit feiner Granularität Pflicht.

Im KMU-Allgemein-Bereich ist RBAC sinnvoll ab dem Moment, wo mehr als drei Personen an einem System arbeiten. Ein Zwei-Personen-Büro mit einem zentralen Admin-Account mag akzeptabel sein. Bei vier Personen sind die Risiken – Versehentlich-Löschungen, unbeabsichtigte Änderungen, Datenschutz-Verletzungen – hoch genug, dass eine Rollen-Trennung Sinn macht.

Geschäftliche Empfehlung: Ein Treuhand-Büro, das vor einem Mandanten erklären kann „Ihr Sachbearbeiter sieht nur Ihre Daten, kein anderer Mitarbeitender hat Zugriff", gewinnt Aufträge gegenüber dem Mitbewerber, der das nicht garantieren kann. Mandanten fragen Mai 2026 zunehmend explizit nach.

Wo RBAC über-engineered ist

Ein-Personen-Büro ohne Mitarbeitende, reine Familien-Daten ohne externe Mandanten, ein Hobby-Projekt mit zwei Freunden – hier ist RBAC Overhead ohne Gegenwert. Ein zentrales Admin-Konto mit langem Passwort und Zwei-Faktor reicht.

Problematisch ist auch der gegenteilige Fehler: Manche KMU implementieren ein 12-Rollen-Modell mit 80 feinen Permissions für fünf Mitarbeitende. Das Modell ist niemand mehr überschaubar, neue Mitarbeitende warten Wochen auf den richtigen Zuschnitt, und in der Praxis bekommt jeder am Ende „Power User", weil sonst die Arbeit stockt. Das ist schlechter als kein RBAC, weil es das Gefühl von Sicherheit gibt, ohne sie zu liefern.

Faustregel: Pro Mitarbeitenden-Klasse eine Rolle. Eine 8-Personen-Treuhand braucht typisch 4 bis 6 Rollen, nicht 12. Pro Rolle nicht mehr als 15 Permissions; mehr ist ein Hinweis, dass die Rolle aufgespalten werden sollte oder dass ABAC die bessere Wahl wäre.

Dritte Falle: RBAC ohne Joiner-Mover-Leaver-Prozess. Wer die Rollen sauber definiert hat, aber nicht innert Stunden Zugriff entzieht, hat sich nichts gewonnen – der Mitarbeitende, der am Freitag gekündigt wurde, hat am Montag noch Zugang. Der Prozess ist genau so wichtig wie das Modell.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. NIST SP 800-162 – Guide to Attribute Based Access Control (ABAC) · 2026-03
2. BSI – IT-Grundschutz-Baustein ORP.4 Identitäts- und Berechtigungsmanagement · 2026-02
3. Verizon Data Breach Investigations Report 2026 · 2026-04
4. Authelia – official documentation · 2026-04
5. Authentik – official documentation · 2026-05
6. Keycloak – Server Administration Guide · 2026-04