Owner, Editor, Viewer: Wie Rexfins Berechtigungsmodell tatsächlich funktioniert

Berechtigungsmodelle in kleinen SaaS-Tools tendieren zu einer von zwei schlechten Formen: Entweder kann jeder alles, weil das Team klein ist, oder das Tool bekommt ein enterprise-taugliches RBAC-System aufgesetzt, das auf einem Drei-Personen-Finanzteam niemand verlangt hat. Rexfin hat einen schmaleren Mittelweg gewählt: drei Rollen, jede mit einer klar unterschiedlichen Aufgabe, jedes Mal serverseitig durchgesetzt – nicht nur aus dem Menü versteckt.

Drei Rollen statt einer Berechtigungsmatrix

Eine Owner-Person kann Kolleginnen und Kollegen einladen, die Rolle jeder Person ändern und Mitglieder deaktivieren – die einzige Rolle, die das kann. Eine Editor-Person kann Dokumente hochladen, sie prüfen, Szenarien durchspielen und Exporte erzeugen. Eine Viewer-Person kann Dashboards und Statements einsehen und Fragen stellen, aber nichts hochladen oder verändern. Das entspricht bewusst genau dem, was die meisten Finanzteams tatsächlich brauchen: jemand, der den Workspace führt, Menschen, die die Arbeit machen, und Menschen, die das Ergebnis konsumieren – grob gesagt eine Controlling-Person, eine Analystin oder ein Analyst und ein Boardmitglied, das den von jemand anderem erstellten Pack liest.

Eine Regel liegt unter allen dreien: Ein Workspace kann nie bei null Owner-Personen landen. Versucht die letzte verbliebene Owner-Person, sich selbst herabzustufen, oder wird sie von jemand anderem deaktiviert, blockiert das System das. Das klingt selbstverständlich, bis man die Race Condition bedenkt, die dadurch verhindert wird: Zwei Owner-Personen, die sich fast gleichzeitig gegenseitig deaktivieren, könnten sonst einen Workspace ohne jede verantwortliche Person zurücklassen. Rexfin schließt das auf Transaktionsebene, nicht mit einem Warnhinweis, den ein schneller Klick überholen kann.

Deaktivierung statt Löschung

Jemanden aus einem Workspace zu entfernen, ist bei Rexfin eine sanfte Aktion, keine harte Löschung. Das Deaktivieren eines Mitglieds macht drei Dinge atomar: markiert die Person als inaktiv, widerruft jede Sitzung, die sie gerade hält, und schreibt einen Eintrag darüber, wer das wann getan hat. Die Person wird sofort ausgeloggt – nicht „irgendwann”, nicht „beim nächsten Ablauf des Tokens” –, weil Sitzungen bei jeder geschützten Anfrage gegen die Datenbank geprüft werden, nicht nur über ein signiertes Cookie am Rand verifiziert werden. Ein deaktiviertes Konto kann sich nicht mehr einloggen, und ein an dieses Konto verschickter Link zum Zurücksetzen des Passworts funktioniert ebenfalls nicht.

Was nicht passiert, ist eine stille Kaskadenlöschung. Kommentare, Szenarien und Audit-Einträge, die eine deaktivierte Person verfasst hat, bleiben genau dort, wo sie waren, weiterhin ihr zugeschrieben, wobei die Anzeige lediglich vermerkt, dass die Person aus dem Team entfernt wurde – so bleibt die Historie intakt, und niemand muss eine Lücke im Datensatz erklären. Eine noch nicht angenommene Einladung lässt sich vollständig zurückziehen. Eine bereits angenommene Einladung kann nicht so zurückgezogen werden, als hätte es sie nie gegeben; das System weist unmissverständlich darauf hin, stattdessen die Mitgliedschaft zu deaktivieren, weil so zu tun, als sei ein aktives Konto nie eingeladen worden, in einem Audit-Trail eine andere und schlimmere Form der Unehrlichkeit wäre.

Jede Änderung wird protokolliert, und Zugriffsversuche über Workspace-Grenzen hinweg laufen ins Leere

Jede Rollenänderung und jede Deaktivierung schreibt eine Zeile in das eigene Audit-Log des Workspace – wer es getan hat, an wem, und was sich geändert hat. Das ist der Datensatz, den Sie einer prüfenden Person geben würden, die fragt „wer hatte wann Zugriff auf diese Daten” – keine Rekonstruktion aus dem Gedächtnis.

Zugriffsprüfungen laufen serverseitig bei jeder verändernden Aktion und sind, bevor irgendetwas anderes ausgeführt wird, auf den eigenen Workspace der anfragenden Person begrenzt. Versucht jemand, auf eine Ressource in einem Workspace zuzugreifen, dem er nicht angehört, bekommt er ein schlichtes 404, kein 403 – das System bestätigt nicht einmal, dass die Ressource existiert, statt lediglich den Zugriff darauf zu verweigern, und das ist relevant, weil ein 403 einer prüfenden Person still verrät „ja, das existiert, du darfst nur nicht ran”, während ein 404 gar nichts preisgibt.

Wo das ins größere Bild passt

Nichts davon ersetzt Enterprise-SSO oder eine vollständige RBAC-Hierarchie – das ist eine bewusste Entscheidung für die Teamgröße, die Rexfin heute bedient, kein Versehen. Wie das mit dem Rest der Plattformkontrollen zusammenspielt, lesen Sie im Überblick zur Sicherheitsarchitektur, und was eine neue Kollegin oder ein neuer Kollege am ersten Tag unter jeder Rolle tatsächlich sieht, in der Begehung der ersten Woche. All das ist zudem Teil dessen, was Rexfin dem Sicherheitsteam einer potenziellen Kundin oder eines potenziellen Kunden direkt zeigt – mehr dazu im Trust Center, oder stöbern Sie im gesamten Hub.